Fix npm ci failing on all CI jobs due to js-yaml override and remove deprecated codecov

[X-Guardian]

Problem

Every workflow that runs npm ci fails during install, before any test or lint step executes:

npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and package-lock.json
npm error or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
npm error
npm error Invalid: lock file's js-yaml@3.14.2 does not satisfy js-yaml@3.15.2

Example failing job: https://github.com/mapbox/node-pre-gyp/actions/runs/34881631492/job/104102066931

This affects .github/workflows/ci.yml and .github/workflows/release.yml, both of which use npm ci. It reproduces on a clean checkout of master with no other changes applied.

Cause

82ec643 ("Support private S3 buckets", #923) added an overrides block to package.json, presumably to lift js-yaml clear of the DoS advisories affecting older 3.x releases:

"overrides": {
  "js-yaml": "^3.14.2"
}

An override range is not pinned the way a dependency is. npm ci re-resolves every override against the registry before installing and compares the result with the lockfile, so a caret range is a live input on every run.

That is why this broke without any commit to point at. When the override was added in November 2025, ^3.14.2 resolved to 3.14.2 and matched the lockfile, so CI was green. js-yaml@3.15.0 was published in June 2026, and from that point the same range resolved to 3.15.x while the lockfile still recorded 3.14.2. The 3.15.2 named in the error appears nowhere in package-lock.json: it is the freshly resolved value of the override.

Fix

Two changes, both in service of making npm ci reproducible again.

Remove the overrides block, and resolve js-yaml forward in the lockfile. With no override left, the version is pinned by the lockfile alone and there is nothing for npm to re-resolve against the registry on each install. A future js-yaml release cannot reintroduce the same failure.

Remove codecov and its upload-coverage script. This is required rather than opportunistic: codecov pins js-yaml to exactly 3.14.1, so dropping the override alone would let npm nest that vulnerable copy straight back into the tree. It cannot be upgraded out of the way either. 3.8.3 carries the pin and is the newest release on the latest tag, published in 2021 and since deprecated by its maintainers in favour of the codecov/codecov-action GitHub Action.

Removing it costs nothing, because it is already dead. The upload-coverage script was invoked from .travis.yml and has not run since Travis was removed in #718 (June 2024); the GitHub Actions workflows that replaced Travis never picked it up, and the repository has no codecov badge, config file, or CODECOV_TOKEN. Local coverage via npm run coverage (nyc) is untouched.

Result

js-yaml                          3.15.2
@eslint/eslintrc/js-yaml         4.1.1
eslint/js-yaml                   4.3.2

No 3.14.1 copy remains, so GHSA-2883-xcg3-v3hh (>=3.0.0 <3.15.2) is resolved rather than merely worked around. The pre-existing npm ls ELSPROBLEMS warning, caused by codecov's unsatisfiable pin, is also cleared. 17 packages leave the dependency tree.

[ox-security]

OX Security reviewed this pull request — nothing to fix.

✔ No issues found

Branch fix/npm-ci-lockfile → master

View scan in OX Security →

[cclauss]

I dislike pinning Windows. They should be synonymous, but perhaps the docs are lying.

If we are going to unpin Windows, then let's also unpin Ubuntu to 26.04.

the --msvs_version=2022 tests already pass.

npm v12 drops that option, so it is time to start testing npm v12.

• fix(ci): test on npm@12 nodejs/gyp-next#359
• fix(ci): test on npm@12 nodejs/node-gyp#3362

[cclauss]

windows-latest, windows-2025, and windows-2025-vs2026 should be synonymous.
https://github.com/actions/runner-images#available-images

[X-Guardian]

Hi @cclauss, you are right, it made no difference. I will revert that change.

I opened this PR to fix the failing CI to unblock #996, but this has exposed multiple issues with the CI. Do you want to try and resolve them all in this PR, or just keep it to resolving the lock file issue, and raise another PR to resolve the Windows tests?

[cclauss]

Smaller PRs are easier to review and merge.

Incrementalism takes patience but is a building block of open source.

[X-Guardian]

Yep, but it means merging this PR with failing tests...

[X-Guardian]

I'll create an issue for the failing Windows tests

[X-Guardian]

Issue created:

• All Windows CI jobs fail: due to windows-latest now shipping Visual Studio 2026 #998