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

doc: add node protocol to ESM and CommonJS api examples #38620

Closed

Conversation

jeromecovington
Copy link
Contributor

This PR addresses #38343. As far as I can tell that issue may have only been concerned with updating the node: protocol for ESM examples, but I think it makes sense to update for CommonJS examples as well, as it seems to me that it also works for that. I'm not sure if there are other areas of the docs other than the api examples that need this change, that's all I've looked at so far.

@github-actions github-actions bot added the doc Issues and PRs related to the documentations. label May 10, 2021
@jeromecovington
Copy link
Contributor Author

I'll make sure to clean up those markdown lint issues.

Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM although depending on collaborator consensus, landing may have to wait.

@Trott
Copy link
Member

Trott commented May 16, 2021

@nodejs/documentation

Copy link
Contributor

@DerekNonGeneric DerekNonGeneric left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These all look great, thanks.

@DerekNonGeneric
Copy link
Contributor

Well, as @ljharb said, wait until node protocol is backported to LTS. I had not seen that comment yet.

@Trott
Copy link
Member

Trott commented May 17, 2021

Well, as @ljharb said, wait until node protocol is backported to LTS. I had not seen that comment yet.

Are there plans to backport node: to 14.x?

@DerekNonGeneric
Copy link
Contributor

@Trott, core modules should be documented this way. I would say to give it some time for people to gain awareness. I am not aware of any other prior discussions about it though.

Copy link
Contributor

@DerekNonGeneric DerekNonGeneric left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jeromecovington, here is a second-pass review. I will have to get back to you once I have the answer to this, but perhaps @GeoffreyBooth knows what should be stated in these code blocks?

doc/api/esm.md Outdated Show resolved Hide resolved
doc/api/esm.md Outdated
@@ -340,11 +340,11 @@ module default import or its corresponding sugar syntax:

<!-- eslint-disable no-duplicate-imports -->
```js
import { default as cjs } from 'cjs';
import { default as cjs } from 'node:cjs';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems wrong to me after looking at it again. There is no core module named cjs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks I'll be sure to fix this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DerekNonGeneric I fixed this, and a couple other instances of node:cjs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/cc @nodejs/modules if anyone knows why the code blocks here have a cjs specifier

doc/api/esm.md Outdated Show resolved Hide resolved
@DerekNonGeneric DerekNonGeneric added the loaders-agenda Issues and PRs to discuss during the meetings of the Loaders team label May 17, 2021
@targos
Copy link
Member

targos commented May 17, 2021

Well, as @ljharb said, wait until node protocol is backported to LTS. I had not seen that comment yet.

Are there plans to backport node: to 14.x?

No. It was a semver-major change: #35498

Edit: sorry, that was another change...

@Trott
Copy link
Member

Trott commented May 19, 2021

@jeromecovington I don't know how this pull request is going to play out, but thank you for your patience and diligence on this, whatever happens!

@DerekNonGeneric DerekNonGeneric removed the loaders-agenda Issues and PRs to discuss during the meetings of the Loaders team label May 19, 2021
@DerekNonGeneric DerekNonGeneric dismissed their stale review May 19, 2021 04:33

Requested changes have been addressed.

@Trott
Copy link
Member

Trott commented May 23, 2021

@jasnell You seemed to express support for something like this in #38343 (comment). What do you think of this PR?

@Trott
Copy link
Member

Trott commented May 23, 2021

@guybedford Given #38343 (comment), I'm guessing there's nothing that can be done in this PR to address your reservation expressed there. But if I'm wrong, please do indicate what might happen to make this PR something you endorse, or at least don't have any significant reservations about.

@jasnell
Copy link
Member

jasnell commented May 23, 2021

I'm in favor of the change but there's no particular rush on it

@Trott
Copy link
Member

Trott commented Dec 17, 2021

@jeromecovington Thanks for the email ping. If you're up for rebasing to address all the conflicts, this may be ready to go.

@guybedford Is node: well-established enough now that you don't have concerns about documenting it widely like this?

@aduh95 node: is available on 14.x so I imagine the backport-blocked-v14.x can be removed. Is that right?

@guybedford
Copy link
Contributor

@Trott yes I wouldn't block this PR anymore personally.

@ljharb
Copy link
Member

ljharb commented Dec 17, 2021

fwiw use of node: in a package still breaks consumers in surprising ways based on reports across a number of my packages; i'd still prefer node stick with the bare form in the docs.

@aduh95
Copy link
Contributor

aduh95 commented Dec 17, 2021

@ljharb do you have examples of such reports? How is it breaking? I think we could reach out to the maintainers of the tools that don't handle those correctly to gather more feedback on this.

@ljharb
Copy link
Member

ljharb commented Dec 17, 2021

@aduh95 one reason is that the resolve module only understands core modules that the current version of node does. This means if someone's using node 16 in production, but their IDE or editor uses node 12 (which either doesn't, or didn't until recently, support node: in require), they'd get linter warnings despite things working fine in production. There's no good fix here since, eg, vscode doesn't make it easy to change which node version is bundled with it.

Copy link
Member

@jasnell jasnell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm generally +1 on this change but I think we should wait until 12.x reaches end of LTS support in April 2020. Let's mark this PR blocked until then.

@jasnell jasnell added the blocked PRs that are blocked by other issues or PRs. label Dec 19, 2021
@aduh95
Copy link
Contributor

aduh95 commented Mar 23, 2022

@jeromecovington With Node.js v18.0.0 around the corner and Node.js v12.x fading to EOL next month, I think we should consider landing this soon. Would you be available to rebase your branch on top of master and fix all the conflicts?

@jeromecovington
Copy link
Contributor Author

@aduh95 from what I can tell the conflicts are mostly around the addition of cjs/mjs dependency-style code blocks. I should have some time to take care of that later this week or this weekend. Thanks for the heads up.

@jeromecovington
Copy link
Contributor Author

The conflicts are now so significant that I think we'll have better luck just cutting a fresh branch off of master and redoing this work, rather than working toward resolving. I can take a look at that later or if someone else has time, I'm happy to shut down this PR in favor of a more up to date approach.

@aduh95
Copy link
Contributor

aduh95 commented Mar 28, 2022

The conflicts are now so significant that I think we'll have better luck just cutting a fresh branch off of master and redoing this work, rather than working toward resolving. I can take a look at that later or if someone else has time, I'm happy to shut down this PR in favor of a more up to date approach.

FWIW you don't have to create a new PR to start fresh. You can run the following command when on this PR branch:

git fetch https://github.com/nodejs/node.git master
git reset FETCH_HEAD --hard
# now your local git repo is in a fresh state

# and when you're done:
git commit
git push --force-with-lease

That being said, if creating a new PR is more convenient for you, you can certainly do that – whatever you do, I'm grateful for the work you're putting to improve Node.js docs :)

@GeoffreyBooth
Copy link
Member

You can run the following command

We should add this to the contributors’ guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked PRs that are blocked by other issues or PRs. doc Issues and PRs related to the documentations.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants