Windows native build (better-sqlite3/node-gyp) regressed between 2026-08-21 and 2026-09-02: node-gyp cannot parse the windows-latest runner's Visual Studio 18 version string

[tnunamak]

Summary

node-gyp cannot parse the windows-latest GitHub Actions runner's installed Visual Studio version string, so any native-module install (better-sqlite3, this repo's only Windows-native dependency) fails on that runner. This blocks the Windows leg of Release manual-install artifacts whenever a native module needs building — first exposed today (2026-09-02) when reference-implementation (via #42) brought better-sqlite3 into this repo's dependency tree for the first time; nothing in this repo needed a native Windows build before that.

Evidence

Last known green: run 32534810268, 2026-08-21T22:53:33Z — Windows build job success. This ran before better-sqlite3 (or any native module) existed in this repo's dependency tree, so it never exercised the affected code path.

First known red: run 33655519198, 2026-09-02T16:32:14Z (PR #43) — Windows build job failure. Also reproduces identically on run 33646932473, 2026-09-02T15:11:26Z, the first run after #42's landing to include better-sqlite3 in the resolved dependency tree.

Exact error (identical across every red run):

npm error gyp ERR! find VS
npm error gyp ERR! find VS msvs_version not set from command line or npm config
npm error gyp ERR! find VS VCINSTALLDIR not set, not running in VS Command Prompt
npm error gyp ERR! find VS could not use PowerShell to find Visual Studio 2017 or newer, try re-running with '--loglevel silly' for more details.
npm error gyp ERR! find VS
npm error gyp ERR! find VS Failure details: RangeError [ERR_CHILD_PROCESS_STDIO_MAXBUFFER...
npm error gyp ERR! find VS unknown version "undefined" found at "C:\Program Files\Microsoft Visual Studio\18\Enterprise"
npm error gyp ERR! find VS could not find a version of Visual Studio 2017 or newer to use

The load-bearing line: unknown version "undefined" found at "C:\Program Files\Microsoft Visual Studio\18\Enterprise". node-gyp's Visual Studio finder expects a numeric year (2017/2019/2022) in the install path/registry; the runner image now ships an install under a bare \18\ path (a newer VS release-naming scheme), which node-gyp's parser doesn't recognize — it reads the version as undefined and gives up, even though a real, usable VS installation is present.

Bisection limits

Release manual-install artifacts triggers only on pull_request/merge_group/workflow_dispatch (not on every push to main) — there are only 3 runs against main directly in this repo's history, and no PR touched anything requiring a Windows native build between 2026-08-21 and 2026-09-02T15:11Z. So there is no way to bisect the runner-image change itself to an exact date within that window from this repo's CI history alone; the two data points above (last-green, first-red) bracket it but can't narrow further from here. It's plausible the underlying runner-image regression landed anywhere in that window and simply had nothing to trigger it until today.

Why this isn't fixed in #43 or #44

Both are content PRs (a Docker/deploy proof and a consent-picker port, respectively); the fix here is either pinning windows-latest to an older image tag, or updating this repo's node-gyp/npm version to one with the VS-18 naming fix, or provisioning a working msvs_version/VCINSTALLDIR explicitly in the workflow — a CI/toolchain change, not a source change, and out of scope for either PR's own diff.