build(workflows): skip stale msvs_version npm config on Node.js v18/v20

[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• Fixes the windows_test_npm_install workflow, which has failed on every scheduled develop run for the past month. The test_npm_install job fails at the "Configure npm" step on the Node.js v18 and v20 matrix legs with npm error \msvs_version` is not a valid npm option. Skips the npm config set msvs_version 2019` command for those two legs, where it is both invalid and unnecessary.

Related Issues

Does this pull request have any related issues?

This pull request has no related issues.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

Failing run: https://github.com/stdlib-js/stdlib/actions/runs/29010806701

Symptom: test_npm_install job fails at the "Configure npm" step, exit code 1:

npm error `msvs_version` is not a valid npm option

Confirmed via job history on every scheduled develop run going back to 2026-06-11.

Root cause: .github/workflows/windows_test_npm_install.yml's "Configure npm" step unconditionally runs npm config set msvs_version 2019 across the full build matrix. The v18 and v20 legs install NPM_VERSION: '>10.0.0'. npm v10+ validates npm config set keys against a fixed internal schema and rejects the legacy node-gyp hint key msvs_version. The other legs run npm <10, which does not validate the key, so they pass.

Fix: Added if: matrix.NODE_VERSION != '20' && matrix.NODE_VERSION != '18' to the "Configure npm" step, plus a comment explaining why. node-gyp bundled with npm v10+ auto-detects the installed Visual Studio toolset via vswhere (the runner already installs visualstudio2019buildtools in the preceding step), so msvs_version is redundant for those two legs, not required. One file changed, 12 insertions, 0 deletions.

Validation: YAML syntax validated with python3 -c "import yaml; yaml.safe_load(...)". Three independent review passes (correctness, regression scope, style/conventions) — all returned approve, no blocking findings.

Reviewer notes (non-blocking):

• The if: condition is keyed on matrix.NODE_VERSION rather than the actual triggering variable (npm major version). If a future change bumps another leg (e.g. Node 16) to npm ≥10, this step fails again for that leg. Gating on npm version directly, or wrapping the command with a non-fatal fallback, would be more robust. Out of scope here.
• A wording nit in the added comment ("npm v9+") was caught in review and corrected to "npm v10+" to match the actual NPM_VERSION: '>10.0.0' constraint.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

This PR was written primarily by Claude Code as part of an automated CI-failure triage and fix routine, based on live GitHub Actions job log analysis. The fix was reviewed by three independent automated review passes before being proposed here.

---

@stdlib-js/reviewers

---

Generated by Claude Code