tools: fix man-page generation on Windows - #64886
Merged
Merged
Conversation
Signed-off-by: James Ross <james@jross.me>
Collaborator
|
Review requested:
|
nodejs-github-bot
added
doc
avivkeller
approved these changes
Aug 1, 2026
StefanStojanovic
approved these changes
Aug 3, 2026
UlisesGascon
approved these changes
Aug 3, 2026
trivikr
added
the
commit-queue
Collaborator
|
Landed in e2b33e2 |
nodejs-github-bot
removed
the
commit-queue
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I hit this while working on #64606, which changes
doc/api/cli.mdand so needsdoc/node.1regenerated. I couldn't regenerate it natively on Windows at all - I had to run the generator from WSL to get an up-to-date man page committed.Two separate path assumptions in
tools/doc/man-page.doc-kit.config.mjs:changelog/indexwere native paths. doc-kit only reads a value from disk when it parses as afile:URL, andE:parses as a URL scheme (which is from where I tried to run this on Windows), so it tried to fetch them over the network and died withTypeError: fetch failed. Now passed asfile:URLs.inputis a glob pattern, where\is an escape character, so the native path matched no files. The run then spun indefinitely with no log output, which is why this wasn't obvious. Now uses POSIX separators.