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

[X-Guardian]

Summary

Every windows-latest job in ci.yml fails at configure. The GitHub Actions windows-latest image now serves Visual Studio 2026 (18.x) and no longer carries Visual Studio 2022.

There are two independent causes, split across the matrix:

1. Node 20.x — the bundled node-gyp (10.1.0) predates VS 18 support and cannot detect the installed compiler at all.
2. Node 24.x and lts/* — the bundled node-gyp (12.4.0) detects VS 2026 correctly, but test/run.util.js:63 hardcodes --msvs_version=2022, so the detected toolchain is rejected.

Evidence

Failing run: https://github.com/mapbox/node-pre-gyp/actions/runs/35073143327 (all three Windows jobs fail)

The image no longer has VS 2022

windows-latest resolves to the win25-vs2026 image:

• Operating System: Microsoft Windows Server 2025
• Image Release: https://github.com/actions/runner-images/releases/tag/win25-vs2026%2F20260907.229

Cause 1 — Node 20.x: node-gyp cannot see VS 18

gyp ERR! find VS unknown version "undefined" found at "C:\Program Files\Microsoft Visual Studio\18\Enterprise"
gyp ERR! find VS could not find a version of Visual Studio 2017 or newer to use

node-gyp gained VS 18 support in 12.0.0. In lib/find-visualstudio.js, 12.4.0 has:

if (ret.versionMajor === 18) {
  ret.versionYear = 2026
  return ret
}

This block is absent in 10.1.0 and 11.4.2, where the version ladder stops at versionMajor === 17. Verified by diffing find-visualstudio.js across 10.1.0, 11.4.2, 12.4.0 and 13.0.2.

Which node-gyp each job gets, via the bundled npm:

Matrix entry	Node	npm	node-gyp	VS 18 detected?
lts/-1	22.23.2	10.9.8	11.5.0	No
lts/*	24.21.0	11.19.0	12.4.0	Yes
latest	26.9.0	11.19.1	12.4.0	Yes

Only lts/-1 (Node 22) is affected. These aliases float: lts/* moves to Node 26 when it enters LTS in October 2026, at which point lts/-1 becomes Node 24 and the problem disappears on its own — but Node 22 is supported until 2027-04-30, so it needs handling until then.

Cause 2 — Node 24.x / lts/*: hardcoded --msvs_version=2022

node-gyp 12.4.0 finds the toolchain without trouble, then rejects it only because of the pinned version flag:

gyp ERR! find VS checking VS2026 (18.9.12120.119) found at:
gyp ERR! find VS - found "Visual Studio C++ core features"
gyp ERR! find VS - found VC++ toolset: v145
gyp ERR! find VS - found Windows SDK: 10.0.26100.0
gyp ERR! find VS - "2026"
gyp ERR! find VS - looking for Visual Studio version 2022
gyp ERR! find VS - msvs_version does not match this version
gyp ERR! find VS could not find a version of Visual Studio 2017 or newer to use

The flag comes from test/run.util.js:63:

// Test building with msvs 2022
if (process.platform === 'win32') {
  final_cmd += ' --msvs_version=2022 ';
}

Consistent with there being only one blocker on Node 24, it fails fewer tests (not ok 4) than Node 20 (not ok 2, 4, 7, 8, …), which fails earlier and more broadly.

Possible directions

The question to settle first: should node-pre-gyp support building against VS 2026 generally, or is this only about making CI green? Every option below is downstream of that.

Relevant to it: engines is >=18, and the README states support tracks the Node.js release schedule, retiring versions at EOL. Node 20 went EOL on 2026-04-30, so the matrix is currently testing an EOL release — which bears directly on how much the Node 20 breakage is worth working around.

• Remove the --msvs_version=2022 flag from test/run.util.js, letting node-gyp auto-detect. Plausibly fixes Node 24 and lts/*. Does nothing for Node 20, which fails before the version check.

  The flag looks incidental rather than deliberate. It was introduced as --msvs_version=2015 with the comment "since that is more edge case than 2013" — the intent was to exercise a non-default VS version, and the current 2022 value arrived via a mechanical bump in Bump rimraf to 5.0.5 to fix DoS #707. Hardcoding a version means the value needs updating every time the runner image moves, which is how this broke. Auto-detection removes that maintenance entirely.

  Trade-off: test/run.util.js:63 is the only reference to msvs_version under test/, so removing it drops the sole coverage of node-pre-gyp's --msvs_version pass-through (lib/configure.js:15 lists it among known_gyp_args). If that path is worth testing, it would be better covered by an explicit unit test of argument forwarding than by a global flag on every Windows build.

• Force a newer node-gyp for Node 20 (e.g. npm_config_node_gyp pointing at node-gyp ≥ 12). Would fix Node 20, but means CI no longer exercises the node-gyp that Node 20 users actually get — worth weighing, since that is part of what this package integrates with.

• Drop Node 20 from the matrix, since it is already past EOL and the README commits to retiring EOL versions. This removes Cause 1 entirely rather than working around it, leaving only the --msvs_version=2022 flag to fix. Note this is a support-policy change, not just a CI change — engines is currently >=18.

[cclauss]

Please create a pull request that removes testing of EOL versions of Node.js. That will be a no-brainer to review and merge.

[X-Guardian]

Looking at the CI test matrix, the node-version is currently ['20.x', '24.x', 'lts/*']. If I drop 20.x, it will only be testing on 24.x, as this is currently identical to lts/*. I could change 20.x to 22.x as this version isn't EOL until April 2027, but this doesn't help with the VS 2026 issue, as Node 22 bundles npm version 10.9.8 which vendors node-gyp 11.5.0 which still doesn't support VS2026. Thoughts?

[X-Guardian]

Lots of other people having the same VS 2026 issue:

• windows-2025 label is serving the windows-2025-vs2026 image (VS 2026 path layout); breaks VS 2022 paths actions/runner-images#14004
• [Windows] windows-latest and windows-2025 image-label will use Windows Server 2025 with Visual Studio 2026 image in June 2026 actions/runner-images#14017

A workaround seems to be to use the windows-2022 image to keep using VS 2022.

[cclauss]

We want to test what users are using (modern OSes) BEFORE they complain that things are broken.
We should test on both old (but NOT EoL) and new.

[X-Guardian]

OK, so starting with the node-version, do you want to drop 20.x or replace it with 22.x? I suggest replacing it.

[cclauss]

Yes please. Replace.

[X-Guardian]

Done:

• chore: replace the end-of-life Node 20 in the CI test matrices #999.

Note that the CI test jobs will still be failing, initially due to

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

[cclauss]

• With chore: replace the end-of-life Node 20 in the CI test matrices #999 now merged...

We use node-version: ['lts/-1', 'lts/*', 'latest'] which currently translates to [22.x, 24.x, 26.x]. Can you please recreate your table above with these new values?

[X-Guardian]

OK done. I'll just point out that not pinning exact versions causes the pipelines to be non-deterministic and could fail in the future.

Regarding the VS version issue, how about we test on both windows-2022 (VS 2022) and windows-latest (VS 2026)? It would just need a node-gyp bump for the Node 22 on windows-latest test.

[cclauss]

Canary in a coal mine: We want the pipelines to fail if a new version of Node.js breaks us.

CI should tell us our tests are failing BEFORE users complain.

[cclauss]

Regarding the VS version issue, how about we test on both windows-2022 (VS 2022) and windows-latest (VS 2026)? It would just need a node-gyp bump for the Node 22 on windows-latest test.

Let's test both (windows-2022 and windows-latest) until we see that all tests are green. After we are confident, we can slim down that matrix.

Do we have a pull request that does the node-gyp bump?

• See npm v12 dropped support for the --msvs_version option #1000

[X-Guardian]

Let me create a PR with my suggestion so that you can see that pattern.

I would suggest that #997 is merged, otherwise we can't see if any of these changes are working in the CI.