Skip to content

ci: drop Node 18 from matrix; tighten engines to >=20 - #7

Merged
jaschadub merged 2 commits into
mainfrom
chore/drop-node18
Apr 23, 2026
Merged

ci: drop Node 18 from matrix; tighten engines to >=20#7
jaschadub merged 2 commits into
mainfrom
chore/drop-node18

Conversation

@jaschadub

Copy link
Copy Markdown
Contributor

Summary

After the `.mjs` rollup fix (#5), Node 18 now builds and type-checks cleanly — but vitest 3.x with Vite 5 fails at startup on Node 18:

```
Error [ERR_REQUIRE_ESM]: require() of ES Module
.../node_modules/vite/dist/node/index.js
from .../node_modules/vitest/dist/config.cjs not supported.
```

Vitest's internal CJS loader can't `require()` Vite's pure-ESM build on Node 18 (Node 20+ handles this transparently). This is a vitest/vite upstream constraint, not something fixable locally — vitest 3.x effectively requires Node 20+.

Changes

  • Drop `"18.x"` from the CI matrix; keep `"20.x"` and `"22.x"`.
  • Tighten `engines.node` in the monorepo root `package.json` from `">=16.0.0"` to `">=20.0.0"` so npm warns anyone trying to install on an older Node, matching reality.

Test plan

Expected result: CI green on both remaining matrix cells, and the `build-artifact` job running through to upload per-package tarballs.

Node 18 now builds and type-checks cleanly (after the .mjs rollup fix),
but vitest 3.x with Vite 5 fails at startup on Node 18 because vitest's
internal CJS loader can't `require()` Vite's pure-ESM build:

  Error [ERR_REQUIRE_ESM]: require() of ES Module
  .../node_modules/vite/dist/node/index.js
  from .../node_modules/vitest/dist/config.cjs not supported.

This is a vitest/vite upstream constraint, not something fixable
locally. Vitest 3.x effectively requires Node 20+.

- Drop "18.x" from the CI matrix; keep "20.x" and "22.x".
- Tighten `engines.node` in the monorepo root package.json from
  ">=16.0.0" to ">=20.0.0" so npm warns anyone trying to install on
  an older Node, matching reality.
`InMemoryStore.get()` calls `recordAccess()`, which both increments
`accessCount` AND refreshes `timestamp: new Date()`. The test was
asserting the retrieved memory deep-equals the stored memory with only
`accessCount` bumped, which flaked whenever store+retrieve didn't land
in the same millisecond. On the CI Node 22 runner it reliably fails;
locally it reliably passes; it's the kind of test that hides real
behavior and surfaces only as noise.

Assert the stable fields with `toMatchObject` and verify timestamp is
at or after the stored time. Same contract, no flake.
@jaschadub
jaschadub merged commit 57f3b61 into main Apr 23, 2026
3 checks passed
@jaschadub
jaschadub deleted the chore/drop-node18 branch April 23, 2026 19:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant