-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: packages docs feedback #35370
doc: packages docs feedback #35370
Conversation
Review requested:
|
|
||
Since `"not:valid"` is not a valid specifier, `"./submodule.js"` is used | ||
instead as the fallback, as if it were the only target. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per @isaacs's comment this also removes documentation on package fallbacks. This may or may not be controversial to the modules group though but I tend to agree with the sentiment of simplifying the outward documentation for this already-complex field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for following through.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for doing this!
A package could also switch from CommonJS to ES module syntax in a breaking | ||
change version bump. This has the disadvantage that the newest version | ||
of the package would only be usable in ES module-supporting versions of Node.js. | ||
A package could also switch from CommonJS to ES module syntax in a [breaking | ||
change](https://semver.org/) version bump. This has the disadvantage that the | ||
newest version of the package would only be usable in ES module-supporting | ||
versions of Node.js. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a note to help users find the relevant info? Somebody who's new to Node.js may ask themself what are the ESM-supporting versions.
That could go in a separate PR as I see there is no History
section at the top of esm.md
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like a section on compatibility via a new PR would be useful to users actually. Perhaps esm.md could get a history or we could add a module compatibility section that mentions what levels of ESM support can be expected where.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO for myself: add a reference to the support table on #35395 if this PR lands first.
@aduh95 thanks for the review, feedback added. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@guybedford please take a look. After this I don’t think there should be any remaining references to “scope” or “boundary”, please let me know if I missed any.
Co-authored-by: Geoffrey Booth <[email protected]>
Co-authored-by: Geoffrey Booth <[email protected]>
@GeoffreyBooth yes that's all cases of boundary now removed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@guybedford Thanks for working with me on this.
Do we want to link the various “nearest parent package.json
“ references to the new “package.json
and file extensions” section?
Possibly that can be a subsequent PR? Also note that that section no longer
covers the lookup algorithm though.
…On Sun, Sep 27, 2020 at 23:36 Geoffrey Booth ***@***.***> wrote:
***@***.**** approved this pull request.
@guybedford <https://github.com/guybedford> Thanks for working with me on
this.
Do we want to link the various “nearest parent package.json“ references
to the new “package.json and file extensions” section?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35370 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAESFSQEPLEHWVUUD7AINULSIAVE7ANCNFSM4R3KYK3A>
.
|
Can certainly come later, if we think it’s a good idea at all. Not everything needs to be a link. And you’re right, it should link to the “ |
* [`"type"`][] - The package type determining whether to load `.js` files as | ||
CommonJS or ES modules. | ||
* [`"exports"`][] - Package exports and conditional exports. When present, | ||
limits which submodules may be loaded from within the package. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
limits which submodules may be loaded from within the package. | |
limits which submodules can be loaded from within the package. |
subpaths of the package will no longer be available to importers under | ||
`require('pkg/subpath.js')`, and instead they will get a new error, | ||
`ERR_PACKAGE_PATH_NOT_EXPORTED`. | ||
When defining the [`"exports"`][] field, all subpaths of the package will be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When defining the [`"exports"`][] field, all subpaths of the package will be | |
When defining the [`"exports"`][] field, all subpaths of the package are |
...or perhaps:
When defining the [`"exports"`][] field, all subpaths of the package will be | |
When the [`"exports"`][] field is defined, all subpaths of the package are |
`ERR_PACKAGE_PATH_NOT_EXPORTED`. | ||
When defining the [`"exports"`][] field, all subpaths of the package will be | ||
encapsulated and no longer available to importers. For example, | ||
`require('pkg/subpath.js')` would throw an [`ERR_PACKAGE_PATH_NOT_EXPORTED`][] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`require('pkg/subpath.js')` would throw an [`ERR_PACKAGE_PATH_NOT_EXPORTED`][] | |
`require('pkg/subpath.js')` throws an [`ERR_PACKAGE_PATH_NOT_EXPORTED`][] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some micro-nit suggestions, but this looks good to me with or without them.
PR-URL: #35370 Reviewed-By: Derek Lewis <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #35370 Reviewed-By: Derek Lewis <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Some minor adjustments, mostly moving things to present tense and avoiding the ambiguity of _may_. Refs: nodejs#35370 (comment) PR-URL: nodejs#35427 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: James M Snell <[email protected]>
Some minor adjustments, mostly moving things to present tense and avoiding the ambiguity of _may_. Refs: #35370 (comment) PR-URL: #35427 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: nodejs#35370 Reviewed-By: Derek Lewis <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Some minor adjustments, mostly moving things to present tense and avoiding the ambiguity of _may_. Refs: nodejs#35370 (comment) PR-URL: nodejs#35427 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: James M Snell <[email protected]>
Backport-PR-URL: #35757 PR-URL: #35370 Reviewed-By: Derek Lewis <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Some minor adjustments, mostly moving things to present tense and avoiding the ambiguity of _may_. Refs: #35370 (comment) Backport-PR-URL: #35757 PR-URL: #35427 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: James M Snell <[email protected]>
Backport-PR-URL: #35757 PR-URL: #35370 Reviewed-By: Derek Lewis <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Some minor adjustments, mostly moving things to present tense and avoiding the ambiguity of _may_. Refs: #35370 (comment) Backport-PR-URL: #35757 PR-URL: #35427 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: nodejs#35370 Reviewed-By: Derek Lewis <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Some minor adjustments, mostly moving things to present tense and avoiding the ambiguity of _may_. Refs: nodejs#35370 (comment) PR-URL: nodejs#35427 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: James M Snell <[email protected]>
This PR brings through the deferred feedback from #34748 from myself and @isaacs.
I carefully ensured to mention all items brought up there in this PR including renaming "package scope" to "package boundary" and adding a summary section to the list of fields.
Further review suggestions very welcome. This should then unblock #34970 and subsequent PRs from release.
@nodejs/modules-active-members @nodejs/documentation @aduh95
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes