golem15/msd-core
4
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity

fix: revert execNpm import in check-env.cjs, keep the diagnosis improvement

Browse Source 
The execNpm-routing redesign (previous commit) broke every real CI job:
check-env.cjs runs as its own standalone "Environment check" step BEFORE
`npm ci` / `npm run build:lib` -- a deliberate pre-flight, run before
there is even a node_modules to build with. Its require of
../gsd-core/bin/lib/shell-command-projection.cjs (a tsc-compiled artifact
that plain does not exist at that point in the pipeline) crashed with
MODULE_NOT_FOUND on every platform, immediately, confirmed via the real
CI log. My own local gsd-test run never caught this because it doesn't
replicate that exact pre-build step ordering.

Reverted the cross-module require entirely; check-env.cjs is back to a
self-contained spawnSync(npmCmd, ...) call, no requires reaching into
gsd-core/bin/lib. Kept the two things actually worth keeping from that
detour:
  - the 15_000ms timeout (matches execNpm's own default elsewhere in this
    repo -- not invented, an existing precedent -- vs. the original 10s
    that failed twice under real Windows CI contention);
  - computing `timedOut` via `error.code === 'ETIMEDOUT'` inline (the
    same canonical, cross-platform-correct predicate that seam uses),
    rather than the earlier signal === 'SIGTERM' check, which that seam's
    own docstring documents as platform-fragile with a Windows-specific
    false-negative risk.

Manually verified check-env.cjs runs correctly with gsd-core/bin/lib
temporarily removed entirely (simulating the real pre-npm-ci CI
ordering) before re-running gsd-test, since this repo blocks local
node --test.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
sim
2026-09-09 07:23:00 -04:00
parent 1cd17cc3d6
commit 8731a90be6
3 changed files with 63 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
scripts/lib/npm-version-check-diagnosis.cjs
View File

@@ -2,30 +2,38 @@
/**
* #4460: distinguishes WHY scripts/check-env.cjs's npm-version check's
* execNpm(['--version']) (the canonical OS-shell-projection seam,
* src/shell-command-projection.cts) produced no usable output, instead of
* collapsing every case into "npm binary not found on PATH" -- a message
* that used to fire identically for a genuinely-missing binary AND for a
* spawnSync TIMEOUT under CI load (exitCode stays non-zero, stdout stays
* empty, either way). Root-caused live: an unrelated PR's Windows CI shard
* failed this check twice in a row while running ~51 concurrent test
* spawnSync(npmCmd, ['--version'], ...) produced no usable output, instead
* of collapsing every case into "npm binary not found on PATH" -- a
* message that used to fire identically for a genuinely-missing binary AND
* for a spawnSync TIMEOUT under CI load (exitCode stays non-zero, stdout
* stays empty, either way). Root-caused live: an unrelated PR's Windows CI
* shard failed this check twice in a row while running ~51 concurrent test
* files; npm.cmd's own cold-start plausibly exceeded the check's original
* 10s window under that contention, and the misleading message made a real
* timeout indistinguishable from npm actually being absent.
*
* Uses `result.timedOut` (execNpm's canonical, cross-platform-correct
* timeout predicate -- `error.code === 'ETIMEDOUT'`, per
* shell-command-projection.cts's isSpawnTimeout docstring) rather than
* checking `result.signal === 'SIGTERM'` directly: that check is documented
* there as platform-fragile, with a specifically-called-out risk of a false
* NEGATIVE on Windows -- the exact platform this failure was discovered on.
* Expects `result.timedOut` to already be computed the same way this
* repo's canonical OS-shell-projection seam (execNpm / isSpawnTimeout,
* src/shell-command-projection.cts) computes it: `error.code ===
* 'ETIMEDOUT'`, which Node's spawnSync guarantees when its own `timeout`
* option fires. NOT imported directly here -- check-env.cjs deliberately
* cannot depend on that seam's compiled output (gsd-core/bin/lib/*.cjs), a
* tsc build artifact that does not exist yet when check-env.cjs runs as its
* own standalone pre-`npm ci` CI step (confirmed live: an earlier version
* of this fix routed through execNpm directly and crashed every real CI
* job with MODULE_NOT_FOUND) -- so the same ETIMEDOUT check is computed
* inline in check-env.cjs instead. Checking `result.signal === 'SIGTERM'`
* directly (what an earlier version of this fix did) is platform-fragile
* per that seam's own documented reasoning, with a specifically-called-out
* risk of a false NEGATIVE on Windows -- the exact platform this failure
* was discovered on.
*
* Kept out of scripts/check-env.cjs itself (which runs its CLI unconditionally
* on require, with no `require.main === module` guard) so this pure logic
* can be required directly by tests without triggering a real environment
* check.
*
* @param {import('../../src/shell-command-projection.cts').SpawnResultOutput} result
* @param {{exitCode: number, stdout: string, signal: string|null, error: (Error & {code?: string})|null, timedOut: boolean}} result
* @returns {string}
*/
function describeNpmVersionCheckFailure(result) {