npm maintained module naming conventions

[nlf]

the npm cli team is responsible for maintenance of a rather large number of modules, these range from truly general purpose, to literal npm cli implementations of commands and anywhere in between. listed below are a few examples.

general purpose:

• cacache
• make-fetch-happen
• @npmcli/promise-spawn

for npm (cli or packages) specifically, but have outside use cases:

• npm-registry-fetch
• pacote

literal npm cli command implementations:

• libnpmpublish

it's clear that overall these package names do not follow a consistent convention, and in some cases the inclusion (or exclusion) of a scope may imply meaning to the package that is undesirable. for example the name @npmcli/promise-spawn seems to imply the module is specifically for the npm cli, while in reality it is nothing more than a wrapper around child_process.spawn() that returns a promise and is very widely useful.

to that end, we should introduce another scope @npmoss and formalize in writing how we determine which scope to place a module in.

• @npmoss: truly general purpose modules, such as @npmcli/promise-spawn and make-fetch-happen
• @npmcli: modules that are specific to the npm cli or npm packages, such as @npmcli/arborst, libnpmpublish, and pacote

while this is easy to adopt for net new packages, it does also mean that quite a few packages will have to be categorized and renamed for their new scopes. when renaming, we should select a scope based on the module's documented purpose and then consider if further name changes are warranted for clarity or simplification.

as an example, make-fetch-happen is a truly general purpose fetch implementation with retries and caching that can be used for any purpose and so belongs in @npmoss. in addition the full package name is to avoid collisions in the unscoped namespace, but moving it to a scope removes that limitation allowing us to sensibly name it @npmoss/fetch.

packages such as libpmpublish are literal cli command implementations so belong in @npmcli, and due to the scope we no longer need to specify that they're for npm, so a sensible new name would be @npmcli/libpublish.

TL;DR

we should:

• create an @npmoss scope
• move general purpose modules to the @npmoss scope, consider renaming further for clarity.
• move npm (cli/registry/node_modules) specific modules to the @npmcli scope, consider renaming further for clarity.

there will be some exceptions to these guidelines, such as tar which was written to support the npm cli and is highly general purpose, but is already named the best possible thing.

Bike shed

is @npmoss the right name for the new scope? some alternatives: @npmutils, @npm-utils (we'd also make @npm-cli for consistency), @npm-oss (also with @npm-cli), @npmjs

[ljharb]

npmoss seems like a strange name to me; all the packages discussed here are OSS. Why not “npm” or “npmjs”?

[nlf]

@npm is a scope we often point to our private registry for internal services, and some of those services may also use the packages we would want to move there. since we can't get packages from two different registries for the same scope, that creates a bit of a problem.

@npmjs is a viable alternative, though. i was leaning on the "open source software" acronym making it clear, but if it's not then we should consider something else. we want the name of the scope to convey "the npm team built and maintains this, but it's useful for everyone"

[ljharb]

Everything in npmcli falls into that category too :-) it’s not for npm to declare that only npm can find its open source software useful.

[nlf]

No, it's not, but there is a clear and distinct separation between modules that are only capable of working on npm related tasks and those that are valuable to anyone. For example make-fetch-happen is just a fetch implementation with caching and retries, while npm-registry-fetch is specifically for fetching package data from an npm registry

[ljharb]

npm-related tasks are automatically valuable to everyone.

[darcyclarke]

Update ^(07/26/2021)

Decisions/outcomes from internal conversation

• ✅ move libnpm* libs into npm/cli repo (as workspaces) & publish under @npmcli/*
• ✅ net-new packages follow @npmcli/*