-
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: fix links to ECMAScript module resolution #52883
Conversation
Review requested:
|
5f8d64f
to
b5ed21f
Compare
Thinking about this a bit more, I wonder if it would be preferable to just make use of 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.
You changed a lot of files for a simple link adjustment, why was that?
It's hard to review when a PR changes several aspects, so the pre
changes seem unneeded.
Tip
I am a triage member, and this review has no standing relative to the core collaborators.
@@ -235,7 +235,7 @@ the `require.resolve()` function. | |||
Putting together all of the above, here is the high-level algorithm | |||
in pseudocode of what `require()` does: | |||
|
|||
<pre> |
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.
Why was this changed?
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 covered in the commit message prior to this change being introduced: 490b02a. What should I change in there to better articulate the issue?
tools/doc/html.mjs
Outdated
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.
In my opinion, the change of this file warrants its own PR
tools/doc/markdown.mjs
Outdated
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.
In my opinion, the change of this file warrants its own PR
tools/lint-md/lint-md.mjs
Outdated
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.
In my opinion, the change of this file warrants its own PR
@nodejs/documentation Personally, I'm -1 on the change in its current form, but I'm just a triage member, and I'd be curious to see one of your reviews. |
`make doc-only` skips the process of building Node, which speeds things up considerably for new contributors.
Within the API documentation for modules, there is a section of pseudo-code which contains links to another file. This pseudo-code is inside of a pre-formatted element (`<pre>`), but that prevents the build process from rewriting those links from the Markdown source to their corresponding HTML output. This addresses that by adding a new language, "pre", whose output remains unformatted but allows code fences to be annotated with metadata - code fences must have a language before the metadata. When the right metadata ("html") is present, it indicates that the code block should be processed so that anchor tags are rewritten just like other references. The actual change to the documentation will happen in a later commit.
The heading in esm.md was changed from "Resolver Algorithm Specification" to "Resolution Algorithm Specification" back in ccada8b. This also makes use of the changes in the previous commit to rewrite the links to point to the generated HTML.
Looking through the GitHub interactions for this project, it appears as though commits within a Pull Request are always squashed. Is that correct? If so, then I agree this Pull Request should be broken into three different ones to preserve their commit messages. |
Yes, the project tends to try and keep one PR per chance (hence the one commit per change) |
Commits are not always squashed. What's important if you want to keep 3 separate commits is that they each have a valid commit message, the project builds, and tests pass on each one of them. |
I'm on the side that this is more than a single change, and should be split into multiple PRs. |
With all due respect, could you please refrain from doing code reviews in a way that sounds that you are a code owner. We appreciate your engagement, but again, regular contributors won't be able to distinguish these comments. Please, avoid giving instructions to contributors |
I'm sorry for overstepping, I'll make sure to not sound like a code owner in the future. Sorry for my repeated misunderstandings, I'm trying my best to learn the works and I'll keep on trying to do better |
No worries, I think you're trying to make it clearer about your role in the project, and your reviews in PRs are more than welcome. Anyone is welcome to peer-review PRs, being part of the project or not. What I'd recommend is leaving personal/biased feedback/code-review changes out from here and letting the core collaborators comment on those matters, not to mention that the wording can make miles of a difference here. I understand that, as a non-native, that's challenging. Keep doing good work :) |
(btw I'm assuming you're a non-native English speaker, but I might be wrong with that regard!) |
This addresses two classes of issues with a few links in the modules API documentation. The first fix is the trivial rename of a section header. The second fix involves rewriting links during the generation of the output HTML. As it is now, the links in the pseudo-code on this page take you to the Markdown source instead of the HTML page. I believe this changeset should fix that. I did my best to change as little as possible in the generated output.
Here are the changes that this makes to the generated output: