Fix #831 - Pinned npm version with corepack

[oleksandr-danylchenko]

Prerequisites

• I have read and follow the contributing guidelines
• I have read and accept the Contributor License Agreement (CLA) Document and I hereby sign the CLA

Type of Change

Chore, fixes #831

Description

Please include a summary of the change (current behavior vs new behavior), which issue is fixed (you can also link to an open issue here), and why this change is necessary.

I pinned the packageManager version with the corepack use npm. Now all the contributions would adhere to the same npm version, avoiding potential package-lock.json conflicts.

Additionally, I adapted GH Actions to use the corepack-installed npm version instead of the one provided by the setup-node action. Unfortunately, there's still a "bug" in the GH runner that requires running the setup-node twice: actions/setup-node#531 (comment). But I referenced it in the comment for maintainers

Impact

It may require the contributors to accept the corepack install prompt once they run the npm i. But nothing "breaking" per se.

[oleksandr-danylchenko]

Hello, @faisalman 👋🏻

There seems to be an oversight in the packag-lock.json file. It still uses the 2.0.9 version instead of the new 2.0.10, introduced in 4121c59

ua-parser-js/package.json

Lines 2 to 4 in 4121c59

	"title": "UAParser.js",
	"name": "ua-parser-js",
	"version": "2.0.10",

ua-parser-js/package-lock.json

Lines 2 to 3 in 4121c59

	"name": "ua-parser-js",
	"version": "2.0.9",

In this PR, I ran npm install to align both. Could you please take a look?

[oleksandr-danylchenko]

Interesting...

Copilot says that:

The root cause is actually the packageManager field that this PR adds to package.json:

"packageManager": "npm@11.14.1+sha512.6a8a4d674..."

Here's the chain of events that causes the failure:

1. packageManager field activates Corepack's integrity checking. When Corepack sees this field with a sha512 hash, it attempts to verify the pinned npm version against the npm registry's signing keys.

2. npm registry rotated its signing keys. The new key ID (SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U) was introduced after Node.js 22.13.1 was released, so the version of Corepack bundled inside that Node.js release simply doesn't know about it.

3. The result: Even the very first npm config get cache invocation fails because Corepack's shim intercepts it, tries to verify, and throws Cannot find matching keyid.

[oleksandr-danylchenko]

The allowScripts is a new feature of the NPM 11.16.0 release:

• https://www.gitclear.com/open_repos/npm/cli/release/v11.16.0
• feat: Phase 1 of allowScripts opt-in install-script policy npm/cli#9360

---

Install behaviour is unchanged. Scripts still run as they always have. The only Phase 1 user-visible change is one advisory block at the end of npm install listing packages whose install scripts haven't been reviewed via the new allowScripts field in package.json. A future release will turn that advisory into an actual block.