-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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: update guidance for adding new modules #44576
Changes from all commits
b4b1ced
9b3ae9a
e82833b
347453e
621a8b0
d129114
af6919e
a9fe2fe
0b19d4e
c524819
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -392,13 +392,21 @@ metadata. Raise a pull request like any other change. | |
|
||
Treat commits that introduce new core modules with extra care. | ||
|
||
Check if the module's name conflicts with an existing ecosystem module. If it | ||
does, choose a different name unless the module owner has agreed in writing to | ||
transfer it. | ||
New modules must only be added with the `node:` prefix. | ||
|
||
If the new module name is free, register a placeholder in the module registry as | ||
soon as possible. Link to the pull request that introduces the new core module | ||
in the placeholder's `README`. | ||
When adding promises to an existing API, add `/promises` | ||
(`inspector/promises`, etc.). Apply the `semver-major` label to the addition. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if node added a semver-major change that prevented any slashed requires/imports from core module names, then this category would no longer be semver-major after that. (edit: oops, this was mentioned here: #44576 (comment) ) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I created #44651 for that. |
||
|
||
If the new module name is free in npm, register | ||
a placeholder in the module registry as soon as possible. Link to the pull | ||
request that introduces the new core module in the placeholder's `README`. | ||
|
||
If the module name is not free and the module is | ||
not widely used, contact the owner to see if they would be willing to transfer | ||
it to the project. | ||
|
||
targos marked this conversation as resolved.
Show resolved
Hide resolved
|
||
We register a placeholder without the `node:` prefix whenever | ||
possible to avoid confusion and typosquatting attacks. | ||
|
||
For pull requests introducing new core modules: | ||
|
||
|
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.
It seems very unfortunate to reify this when it seems a clear decision was not, in fact, made. Why can't this go to a new vote where the intention is made clear from the start?
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.
If anybody on the @nodejs/tsc feels there is not consensus in the TSC on this point, and we should have a vote, either chime in on the issue, or contact me privately if you prefer and I'll move for a vote. Otherwise we'll assume consensus unless I hear from somebody by the next TSC meeting. I'm happy to have a vote if needed but our governance only requires one if we can't reach consensus among the TSC first.