Workflow: Update to latest matching npm when publishing packages

[sirreal]

What?

Fix an error that prevented packages from being published by a stale npm version:

https://wordpress.slack.com/archives/C02QB2JS7/p1704969229967829

See this action:

✖ node ./bin/check-latest-npm.js found some errors. Please fix them and try committing again.
Latest npm check failed!
Error: The local npm version does not match the expected latest version. Expected 10.2.5, found 10.2.3.

Why?

The check-latest-version script runs on package changes but fails if we're not using the latest published npm version that satisfies our engines.npm field in package.json.

How?

Install the latest satisfying npm version.

Testing Instructions

I'm really not sure. You can test that the commands work by running them locally. BEWARE: running this would change the globally installed npm version.

npm install --global npm@"$(jq --raw-output --join-output .engines.npm package.json)"

[ockham]

The code looks good.

However, I'd like to echo @gziolo who suggested removing the npm version check altogether. (The current discrepancy seems negligible: Expected 10.2.5, found 10.2.3.)

This suggestion seems to make some sense to me; I'm not sure what value we're getting out of the check. Since we're already pinning the node version, shouldn't that guarantee us that the suggested counterpart npm version won't suddenly be bumped outside a patch (or maybe minor) upgrade?

I.e. as long as we've set node to v20, can't we expect it to always require npm 10.2.x? If we can, then the npm version check seems somewhat obsolete 🤔 Might be worth digging a bit why we introduced the check in the first place...

[ockham]

Might be worth digging a bit why we introduced the check in the first place...

Found this: #21306

This pull request seeks to add a pre-commit task which verifies that any changes to the root package-lock.json can only be committed if the local NPM version matches the latest available NPM version. This is in line with the documented required environment, and is intended to resolve cases where package-lock.json is wrongly updated with invalid values due to use of outdated version of NPM (see #16157 (comment)).

Edit: Maybe that's no longer an issue with more recent versions of npm.

[sirreal]

I think it's valid to require a specific NPM version. There are a lot of things we could do here, but I'd like a quick fix that doesn't involve rethinking flows, checks, requirements, or anything else. We're blocked on package publishing (and behind) until we get some fix for this.

This type of thing wouldn't be an issue with Volta #28967

[sirreal]

This worked I believe. This workflow published development versions of the packages (from this branch): https://github.com/WordPress/gutenberg/actions/runs/7490854475/job/20390678975

[gziolo]

The check for using the latest npm version most likely doesn’t apply anymore. In the past, in npm 6.x we would see very subtle changes in the lock file even between bug fix npm releases. However, it’s something I haven’t seen myself as an issue starting from npm 7 so we should try removing the requirement in the pre-commit check from using the latest npm version and stick to what Node installs.

[sirreal]

I intended this to be a quick fix without much to discuss for a high priority issue. We're unable to publish packages now.

I would be happy to get rid of the requirement to be on the latest matching npm version, it's been a headache for me personally as the check is broken on my system.

I'll prepare a new PR that removes the npm version check. I'm a bit concerned as it's a bigger change and we'll have less confidence on matching npm versions. Maybe it won't be a problem and if it is we can always reintroduce a check.

[sirreal]

Here's a PR to remove the check completely: #57797