-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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: document support for package.json fields #34970
Conversation
Review requested:
|
1cbd8dc
to
866748b
Compare
866748b
to
46af08f
Compare
The big question here seems to be whether this is a reference or a guide. I get the feeling we should treat this page as the full reference documentation, while treating the ESM modules page as the "read through guide". As such, we should probably aim to include the full semantics of exports as full reference documentation here, including eg conditional exports. Then rather focus on making the entry points section in the ESM documentation the clear and simple guide version for new users. That is - I think we should focus on making this the technical content, and perhaps less on trying to make it accessible to beginners, and put the beginner focus into the ESM modules documentation page. Let me know if that sounds like a sensible approach to you further. This PR does touch on both which is tricky as it is two jobs in one, unfortunately the PR model doesn't fit that well for docs development! Happy to discuss ways to make it easier too. |
Just reading through what we have for the ESM docs now, and of course all the guide info is in the packages page here so the ESM docs actually seem much more like a reference now to me. Of course all the pages are both reference and guide information, but in the past the ESM page always had a flow at the top that you could follow to learn the basics all the way through (or at least that was the attempt). If this package page is going to take that place, then we should move the "package reference" to the bottom of the docs page here rather, and treat the top of this page as more like a guide to getting started. The other option is to make this pure reference, and structure everything by the package.json fields, as pure reference material, do the same for the ESM page, then work to create a separate modules guide. The hard part is splitting up the material that was written the other way around so it becomes quite complex. I don't want to make unnecessary work for anyone though, so won't obstruct progress on what people feel is best. |
46af08f
to
2e3865f
Compare
I've moved the
@guybedford the documentation of conditional exports is already on the same page, do you mean merge it with the |
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.
This reordering makes all the difference, thanks @aduh95.
In terms of splitting more of the definitions as references under the package.json fields section, that is something we can do gradually in follow-up PRs to make the guide at the top shorter and as appropriate and makes sense and perhaps we don't even do that though as well.
51e29c4
to
b70cf5a
Compare
63b107f
to
dd17bc9
Compare
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.
This is looking almost good to go to me, it would be nice to get these docs changes in before the next release, so +1 to merging sooner rather than later to keep iterating.
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.
Can you please point out where you've rewritten sections rather than simply moved them? I'd like to separate the effort of moving the sections from revising them as much as possible, so the history is easier to follow.
Originally what this PR did was:
Rewritten content was added to it based on suggestions from other collaborators in this thread.
You and me both, fella ;) All suggestions were backed by a rationale that seemed reasonable to me, but I have no problem if you prefer we drop it for now. Apologies for the |
Okay, I reread the new This looks fine to me once we resolve #34970 (comment). |
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.
Assuming make lint
passes (I see warnings in GitHub) then this looks good to land.
019b618
to
e1470cf
Compare
I've fixed the linter issue, and squashed the commits so the commit queue can deal with the PR 👍 |
Landed in 541d296 |
e1470cf
to
541d296
Compare
this changeset is currently pending the feedback items proposed on #34748 thus not landing on v14.x just yet |
Fixes: nodejs#33143 PR-URL: nodejs#34970 Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Fixes: nodejs#33143 PR-URL: nodejs#34970 Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Adds
package.json
supported fields documentation topackages.md
.Fixes: #33143
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes