[BUG] npm's strict engine check is confusing (when doing npm install npm)

[rotu]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

npm install --global npm does a strict engine check with some confusing options:

1. The check is not strictly enforced for non-global installation.

2. The check is not strictly enforced for npm update --global npm.

3. The error message shown is generic and there's no indication that the check is due to installing npm in particular.

4. The check is enforced by the installing npm, not by the install scripts of the version being installed. So the check is not applied when upgrading from npm@6 or when using another package manager such as yarn or pnpm. After installing, the warnings just taunt you that you made a bad decision and don't tell you how to restore npm to a working state.

   npm WARN notsup Unsupported engine for [email protected]: wanted: {"node":"^18.17.0 || >=20.5.0"} (current: {"node":"16.20.2","npm":"6.14.18"})
   npm WARN notsup Not compatible with your version of node/npm: [email protected]

5. There is no obvious way to do the right thing when upgrading npm, namely installing the newest version compatible with the current node engine. npm install --global npm always resolves to npm@latest.

---

See npm/template-oss#350 (comment)

Expected Behavior

No response

Steps To Reproduce

1. In this environment...
2. With this config...
3. Run '...'
4. See error...

Environment

• npm:
• Node.js:
• OS Name:
• System Model Name:
• npm config:

; copy and paste output from `npm config ls` here

[ljharb]

You're right there's no "install the latest compatible npm" logic; the only place in the ecosystem that captures that rn is nvm's nvm install-latest-npm.

[ehoogeveen-medweb]

Relatedly (I think): While on node@16 and npm@9,

• npm outdated -g will list npm@10 in both latest and wanted, even though it's a major version change (which are normally prevented via the semver rules)
• npm update -g (without specifying npm) will update to npm@10, even though it's not compatible with node@16

Thankfully it still works well enough to downgrade to v9, but I'm concerned about what might happen in future versions!

[ljharb]

@ehoogeveen-medweb major version changes aren’t prevented by semver rules, it’s that usually package.json has ^ - but there’s no global package.json, so all updates , including breaking changes, are in-range.

I wouldn’t suggest using either command with -g, since there’s no package.json for them. Instead, explicitly update your global deps (for which there should be very few) one at a time.

[ehoogeveen-medweb]

@ljharb The documentation for npm update disagrees:

npm update -g will apply the update action to each globally installed package that is outdated -- that is, has a version that is different from wanted.

Note: Globally installed packages are treated as if they are installed with a caret semver range specified. So if you require to update to latest you may need to run npm install -g [<pkg>...]

In this case wanted points to version 10, in disagreement with the note. I don't know if it's a special exception for npm or if the note is wrong in general. Either way I think wanted should take the node version range into account.