build-win64 and build-win-arm64 both failed in v10.93, and both had already built the bundle and compiled its native modules. What killed them was one line of releases/bump-bundle-npm-deps.mjs:

  Error: spawnSync npm ENOENT

npm on Windows is npm.cmd, a batch script, and Node applies no PATHEXT when it spawns - so execFileSync('npm', …) resolves to nothing. build-win32 was skipped that run for want of a published Node.js build, so it never reached this and looked fine; the fault was never architecture-specific.

npm’s own CLI is run with the Node already running instead: execFileSync(process.execPath, [npm-cli.js, …]). No PATH lookup, no PATHEXT, no shell - and the same npm either way. shell: true would have found the .cmd and broken differently, because with a shell Node joins the arguments and quotes NOTHING, so the first Windows temp path containing a space would corrupt the install. A bare npm on PATH remains as the last resort, for a Node with no npm beside it, and on Windows it now says which case that is rather than letting ENOENT speak for itself.

Verified end to end: a bundle-shaped tree holding qs 6.0.0 is bumped to 6.15.3 through the new path, with the dependencies the new version needs copied in beside it.

build-sandstorm failed with App exceeds uncompressed size limit of 1 GiB and nothing else. Because Sandstorm refuses to pack, no .spk is written, so there is no artifact to open and no list of what filled it.

sandstorm-pkgdef.capnp packs alwaysInclude = ["."] from .meteor-spk/deps AND .meteor-spk/bundle, so both count towards that limit: the Node 24, FerretDB v1, mongod 3.0, niscud and Mongo 3.x CLIs that sandstorm-src/build-deps.sh assembles, and every package the built bundle carries. The pack step now prints the total and the twenty biggest directories of each BEFORE packing, so the next run names the offender instead of only saying that one exists. It cannot fail the build: a size report that breaks a release would be worse than the silence it replaces.

What to trim is recorded in # TODO Later rather than guessed at, with the two candidates worth measuring first - the Sandstorm leg is the only one that never runs prune-build-only-modules.mjs, which drops 83 of 120 packages everywhere else, and the deps tree carries two database engines because the Mongo-to-FerretDB migration needs both. Which of those can go needs a run to answer, and this is what makes that run informative.