⚠️ [RRFC] Breaking changes for `npm@8`

[nlf]

Motivation ("The Why")

• Consolidate comms & desired feature-set for next version of the npm CLI (ie. v8)
• We are approaching the node@16 "Active LTS" Release milestone & want to make some decisions quickly
• In this next release our team has expressed an interest to...
  • minimize breaking changes
  • increase supportability while decreasing our maintenance burden
  • align more closely with node's release cadence & versioning (ex. keeping odd numbers as more experimental)

How

• npm@8 drops support for node<12
• npm@8 will refuse to install in node versions it doesn't work with

Dropping node<12

Today, we have rather a lot of workarounds for node 10 to keep things working. Part of this step will involve actively seeking those workarounds and removing them.

This will reduce the overall volume of code we maintain, and allow for simplifying things in other places.

Refuse to install in old node versions

A lesson we learned with the release of npm@7 is that we need to be more careful about how we interact with versions of node we don't work on. Quite a few folks had problems caused by npm@6 allowing npm@7 to be installed in node@8, this is something we intend to resolve.

Actively refusing to install an npm version that does not work with the user's current version of node will help reduce confusion and frustration for our users, as well as reducing support requests. With clear messaging, we can also encourage users to keep their node versions up to date.

Questions and concerns

Please share them here!

[ljharb]

What about the "stricter peer deps" change becoming default?

[wraithgar]

Can we drop the programmatic API so that we can iterate on it in node8 before we (potentially) allow it again?

[wraithgar]

the "flat out refuse to install a version of itself that is incompatible" should land in npm@7

[isaacs]

Dropping the programmatic API should be non-breaking for Node.js, because it doesn't affect npm's use as a CLI. Anyone listing npm as a dependency and using require('npm') will be fine, since they'll still get whatever version they're depending on.

[fbartho]

Why not leapfrog straight to <14? A more aggressive deprecation process might yield even more benefits for NPM’s maintenance.

To be frank, it wouldn’t upset me if there was an NPM major version per major Node version.

[ljharb]

node 12 is still in LTS.

[bnb]

Yeah, Node.js 12 is still actively supported. It would be a mistake to not support something that is still supported by the Node.js project.

[voxpelli]

As most of you probably already know, when dropping support for Node.js 12 many maintainers in the ecosystem has also decided to start adopting ESM, like eg. @sindresorhus and @wooorm: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

Would that be a wish from the npm team as well? For both npm itself and the modules, like @npmcli/arborist, npm-audit-report etc, that make up npm?

And if so, maybe supported versions should be limited to ^12.20.0 || ^14.13.1 || >=16.0.0 as suggested by the post by @sindresorhus?

Or should a move to ESM-style modules wait until at least npm@9? If so, it will be hard to update to any dependencies that are strictly ESM until then.

[mrmckeb]

I think this is a good move. Node 12 is in "maintenance" LTS, not "active" and users wouldn't be forced to move to npm@8.

Something else I'd also like to see in npm@8 is the return of engine-checks, at least for npm and Node versions.