node
node copied to clipboard
nodejs
doc: update guidance for adding new modules
- updated based on decision to use node: prefix in https://github.com/nodejs/TSC/pull/1206
- updated based on agreement in TSC meeting on adding /promises to existing modules as per minutes - https://github.com/nodejs/TSC/pull/1281
Signed-off-by: Michael Dawson [email protected]
Something else discussed in https://github.com/nodejs/node/pull/44250 that we should consider is making new subpath additions (like any other core module getting /promises) allowable as semver-minor. This might be a code change, to ensure that nonexistent subpaths (like process/promises) throw rather than try to resolve to something like node_modules/process/promises; but once that’s done we should update the docs accordingly.
One of the reasons I thought we should PR this in specifically was to make sure we agreed what the vote on https://github.com/nodejs/TSC/pull/1206 meant. I'd thought we had agreed to do what @aduh95 mentions, but from @mcollina's comment and others I believe different people have different views.
I think we've discussed the issue enough time that we should move to a vote on this specific issue relatively quickly. The vote might be if this PR can land or not. Adding to the TSC agenda.
I think we’ve discussed the issue enough time that we should move to a vote on this specific issue relatively quickly. The vote might be if this PR can land or not.
Can we just vote here? Maybe use 👍 and 👎 to vote on whether or not to land this PR?
Can we just vote here? Maybe use 👍 and 👎 to vote on whether or not to land this PR?
@nodejs/tsc does that sound good to you. If we have some +1s and no objections we can proceed with the vote that way.
@mcollina My recollection of the outcome of node:test was that initially there was a desire to have the new module be unprefixed, which meant that test_runner was the best available unclaimed npm name; but more people preferred the shorter name than wanted it unprefixed, so we went with node:test. New global modules aren't created very often, and at this point I think it's very likely that any new ones we want to create will conflict with existing public packages; so the situation you discuss of claiming the public name when available is unlikely to happen in practice. Could we perhaps land this language as is, and on the off chance a new proposed module name doesn't conflict, we could vote to make an exception to allow it without the node: prefix/protocol?
It doesn’t sound like there’s TSC consensus on changing the default from the current “works with and without the prefix” to “only works with the prefix” - unless that’s incorrect, then the latter would be the exception, not the former.
@mcollina in the discussion in the TSC meeting Tomorrow (Wed Sep 14) can you confirm if TSC members are ok voting in this PR ?
The other aspect I'd like to mention is that I think we should be moving people towards using require('node:x') versus required('x').
If we could wave a magic wand and change that overnight I think we likely would. Since that is not possible it will be a long transition but if we are going to have some modules only available with the prefix we should try to move towards that goal(if that is not the case they why have the prefix at all).
Having new modules only be with the prefix will help move the ecosystem in that direction.
It doesn’t sound like there’s TSC consensus on changing the default from the current “works with and without the prefix” to “only works with the prefix” - unless that’s incorrect, then the latter would be the exception, not the former.
I think what we don't have concensus on is whether we had changed the default or not. Some think we did, others think we did not. In either case I think we all want to avoid rediscussing every time there is a new module so voting/documenting is important to close that gap.
Adding https://github.com/nodejs/node/labels/blocked so this PR doesn't land until the next TSC meeting to give folks some time to manifest their opinion if necessary.
From the minutes - https://github.com/nodejs/TSC/blob/main/meetings/2022-09-21.md
discussed today, unless there are objections we’ll move forward and land it tomorrow
Don't see any objections from TSC members so going to land.