-
Notifications
You must be signed in to change notification settings - Fork 3.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
docs: document package.json
's "exports"
field
#7323
Conversation
"./*": "./*.js", | ||
"./*.js": "./*.js", | ||
"./foo": "./path/to/foo.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.
ideally an example would include "./package.json"
, so tools can access the package.json file, and would also show multiple examples including conditions, arrays, etc.
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.
thank you for the feedback, I've now documented conditional exports.
I have also documented fallbacks although I have not yet added examples for fallbacks.
is the thing about conditional exports satisfactory (like the video game)?
sorry about the force push, I started writing in GitHub's editor, copy pasted to vscode to carry on editing there, copy pasted back to GitHub's editor to commit but I apparently failed to paste |
### exports | ||
|
||
The exports field is an object that maps entry points to modules. This field is | ||
supported by Node.js versions including and higher than 12. It acts as a more |
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.
higher than 12
see https://npmjs.com/node-exports-info - there’s actually a pretty complex set of feature support and node version matrix.
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.
do you think it would be better to take out the "higher than 12" comment since the version of NPM these docs are for only supports Node.js ^18.17.0 || >=20.5.0
anyway?
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.
yes - or maybe, "is supported by modern node.js versions"? also this should link to the node documentation of the field, which might be better than having examples here.
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.
I've added your suggestions, how's this so far?
I have made all requested changes. Is this any closer to being merged? |
Given how in-depth a true documentation of |
Yup. I agree and have linked to Node.js's official docs on the |
Isn't there a problem of responsibility here? If npm doesn't know anything about the Why would npm maintainers be responsible for maintaining a documentation about something that they don't own and mantain? And if they do, why this and not all the CLI tools that have been using |
npm doesn't "own" package.json, it just is one of the primary consumers of it. There have always been fields that folks add to it that npm never looks at. Oftentimes they are undocumented, but sometimes they are very much official, like |
Closing in favor of a much smaller footprint + link in #7783 |
Document
package.json
's"exports"
field.