bug: pnpm test:skill fails on Node 24 with ERR_REQUIRE_ESM (vitest 4.1.8 + vite 7.3.3 + std-env 4.1.0)

[DrejT]

Type: bug

Context & use case
Following the contributor guide to run the offline test gate before opening a PR (pnpm test:skill). This is the first command CONTRIBUTING.md tells contributors to run; hitting it at the very start blocks all offline verification.

Expected vs. actual
CONTRIBUTING.md says:

Use the offline gate as your default test command. The plain pnpm test includes LIVE tests… The contributor default is the offline gate, which runs no model calls: pnpm -C packages/reactor test:offline

And package.json defines:

"test:skill": "REACTOR_OFFLINE=1 vitest run tests/open-prose"

Expected: tests run offline with no model key required.

Actual: startup error before any test runs:

failed to load config from /home/vivek/drej/prose/vitest.config.ts

Error [ERR_REQUIRE_ESM]: require() of ES Module
.../std-env@4.1.0/node_modules/std-env/dist/index.mjs not supported.
    at Object.<anonymous> (.../vitest/dist/config.cjs:4:14)
    at _require.extensions.<computed> [as .js]
       (.../vite@7.3.3/.../config.js:35947:9)
    at Object.<anonymous> (/home/vivek/drej/prose/vitest.config.ts:26:21)

Minimal repro
Fresh clone, no model key needed:

git clone https://github.com/openprose/prose && cd prose
pnpm install --frozen-lockfile
pnpm test:skill

Fails immediately at config load, before any test file is read.

Root cause (observed)
Vite 7.3.3 loads TypeScript config files by bundling them through a CJS execution path (loadConfigFromBundledFile). That path uses a custom _require.extensions handler that predates Node's native ESM-require support. vitest@4.1.8 pulls in std-env@4.1.0, which ships only as .mjs (ESM-only). Vite's custom CJS handler can't load .mjs files, so the startup fails.

Note: Node 24 itself can require this file natively (node -e "require('./node_modules/.pnpm/std-env@4.1.0/.../index.mjs')" exits 0). The failure is in Vite's bundler, not in Node's resolver.

Why this matters
The packages all declare "engines": { "node": ">=20" }. Node 24 is within that range. This is a regression on a supported version, not a misconfigured environment.

Environment

• OS: Linux 6.17 (Fedora 41)
• Node: v24.13.0
• pnpm: 9.15.0
• vitest: 4.1.8 (from lockfile)
• vite: 7.3.3 (transitive, from lockfile)
• std-env: 4.1.0 (transitive via vitest, from lockfile)
• Install method: pnpm install --frozen-lockfile from repo root

What I already tried

• Confirmed pnpm install completes cleanly
• Confirmed the error is in Vite's config loader, not Node's native require
• Renaming vitest.config.ts → .mts doesn't help because vitest/dist/config.cjs itself requires std-env before the config file extension matters

Possible fixes (not tested end-to-end)

1. Add pnpm.overrides in root package.json to pin std-env to ^3 (ships CJS)
2. Upgrade to a vitest version where config.cjs doesn't require std-env directly
3. Set "type": "module" in root package.json (broader change, touches the whole workspace)

Happy to test a fix if the maintainer can point me to a preferred solution

[DrejT]

btw this works completely fine on node 22

[devanonyme42]

Hi @DrejT, I tried to reproduce this and could not, including with your exact setup. Fresh clones, pnpm install --frozen-lockfile, so the same vitest 4.1.8, vite 7.3.3 and std-env 4.1.0 from the lockfile:

Node	pnpm	Result
24.18.0	11.6.0	pnpm test:skill green, 27 files, 409 tests
24.13.0	9.15.0	green
24.13.0, frozen lockfile, clean node_modules	9.15.0	green

Your mechanism is right though: std-env 4.1.0 ships ESM only (main: ./dist/index.mjs, no CJS entry), so the require("std-env") inside vitest's config.cjs depends entirely on Node's require(esm) support. On stock Node 24 that support is on by default, which is why the table above stays green. ERR_REQUIRE_ESM should only appear where that capability is missing or disabled.

Two things worth checking on your side: is your node the Fedora 41 package rather than an upstream build, and does node -e "require('std-env')" fail from the repo root in your shell? Also worth a look: a leftover NODE_OPTIONS containing --no-experimental-require-module. If the Fedora build turns out to be the difference, that would point away from pinning std-env or adding overrides here, since the lockfile works as is on upstream Node.