Skip to content
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

Closed
wants to merge 5 commits into from

Conversation

samualtnorman
Copy link

Document package.json's "exports" field.

@samualtnorman samualtnorman requested a review from a team as a code owner March 29, 2024 12:16
Comment on lines 352 to 354
"./*": "./*.js",
"./*.js": "./*.js",
"./foo": "./path/to/foo.js"
Copy link
Contributor

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.

Copy link
Author

@samualtnorman samualtnorman Mar 30, 2024

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)?

@samualtnorman
Copy link
Author

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
Copy link
Contributor

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.

Copy link
Author

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?

Copy link
Contributor

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.

Copy link
Author

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?

@samualtnorman
Copy link
Author

I have made all requested changes. Is this any closer to being merged?

@wraithgar
Copy link
Member

Given how in-depth a true documentation of exports needs to be, I second the idea of linking to Node's documentation on this. Node is what is parsing that field, not npm. main was a very simple spec so documentation was likewise simple. This field, not so simple.

@samualtnorman
Copy link
Author

Given how in-depth a true documentation of exports needs to be, I second the idea of linking to Node's documentation on this. Node is what is parsing that field, not npm. main was a very simple spec so documentation was likewise simple. This field, not so simple.

Yup. I agree and have linked to Node.js's official docs on the exports field.

@ericmorand
Copy link

ericmorand commented Aug 11, 2024

Isn't there a problem of responsibility here? If npm doesn't know anything about the exports field and doesn't use it at all, doesn't it mean that Node.js maintainer actually highjacked package.json to host something that only belongs to them, and should not be there?

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 package.json to host their own custom fields? Where does it stop?

@wraithgar
Copy link
Member

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 main. It's just the reality of how Node.js and npm evolved together.

@wraithgar
Copy link
Member

Closing in favor of a much smaller footprint + link in #7783

@wraithgar wraithgar closed this Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants