web-infra-dev/rstest - CodSpeed

rstest

Blog Docs Changelog

Performance History

Latest Results

ci(codspeed): clear process.execArgv before threads pool snapshot CodSpeed simulation mode injects V8 introspection flags into the parent's CLI (`--allow-natives-syntax`, `--predictable`, `--hash-seed=1`, etc.) for deterministic Callgrind measurement. rstest's threads pool snapshots `process.execArgv` and propagates it to each Worker, but `node:worker_threads` enforces an allow list and rejects those flags with "Initiated Worker with invalid execArgv flags", so every bench fixture failed on the first worker spawn. Clearing the array in the bench entry is safe: the flags have already taken effect on the parent's V8 engine, and the bench fixtures don't need any inherited Node flags in their workers.

ci/codspeed-threads-pool

9 days ago

release: 0.10.0 (#1265)

main

18 days ago

fix(core): guard interop has trap against primitive default export (#1234)

main

25 days ago

docs: use Rspress Prompt component and upgrade to the latest version (#1213)

main

1 month ago

fix(pool): satisfy no-empty lint on killAndWait catch blocks

dp

1 month ago

fix(runtime): use file:// URL href for absolute import specifiers When resolving an absolute import specifier via `pathToFileURL(...)`, `defineRstestDynamicImport` extracted `.pathname` to use as the module path. On Windows that yields `/D:/a/foo.mjs`, which Node's ESM loader later re-resolves against the current drive root, producing `D:\D:\a\foo.mjs` and a MODULE_NOT_FOUND. Switch to `.href` (the full `file:///D:/a/foo.mjs` URL) so the string is a valid import target on both platforms. The downstream checks — `.endsWith('.mjs')`, `.endsWith('.json')`, `.startsWith('node:')`, `shouldInterop`, asModule cache key — all operate on the URL string the same way they did on the raw path; the WASM branch in loadModule.ts already handled a `file://` prefix via `fileURLToPath`. Surfaced by the loadEsModule.test.ts integration tests added in the previous commit, which were the first tests to pass an absolute fixture path through this branch on Windows CI.

dp

1 month ago

fix(runtime): cache vm.SyntheticModule to avoid nodejs/node#54735 crash V8 has a data race in `SyntheticModuleEvaluationStepsCallback` that fires when the same exports are wrapped in multiple `vm.SyntheticModule` instances whose evaluate() calls overlap on the microtask queue — nodejs/node#54735. rstest's `asModule` helpers used to build a fresh SyntheticModule on every call, so any CJS/JSON/Wasm dep imported more than once inside a worker could trigger the segfault. Surfaces as a SIGSEGV during worker bootstrap with the victim test file reported as `(0)` and empty stderr. Structure the wrapping so the cache key can only ever be the resolver's output: - `asModule` now takes a required `resolvedId: string`. Optional `identifier` was the weak link — callers could (and did) reach for raw `specifier`, which is importer-relative and collides across files. - Every SyntheticModule construction lives inside `defineRstestDynamicImport`, where the resolver's absolute path is already in scope. The ESM `link` callback and `importModuleDynamically` hook collapse to pure pass-through — no second wrap site that could re-introduce the wrong key. - Each loader owns a private `Map<resolvedId, SyntheticModule>`. The previous `WeakMap<context, Map<id, SM>>` was dead weight: rstest never creates a custom vm.Context, so every entry landed in the same sentinel bucket. Verified locally with a 50-run repro loop at `maxWorkers=8`, 0 SIGSEGV (baseline reproduced within 7–9 runs). Refs: nodejs/node#54735, vitest-dev/vitest#7741

dp

1 month ago

fix(runtime): cache vm.SyntheticModule to avoid nodejs/node#54735 crash V8 has a data race in `SyntheticModuleEvaluationStepsCallback` that fires when the same exports are wrapped into fresh `vm.SyntheticModule` instances whose evaluate() calls overlap on the microtask queue — see nodejs/node#54735. The original `asModule` helpers new-ed a SyntheticModule every call, so any CJS/JSON/Wasm dep that was re-imported inside a worker was a candidate trigger. Cache the SyntheticModule per `(context, identifier)` pair so each request returns the same instance. Mirrors vitest-dev/vitest#7741. The cache sits behind an optional `identifier` parameter so callers that can't produce a stable key fall back to the old "new each time" path and stay source-compatible. To match vitest's per-executor cache lifetime while keeping rstest's module-level layout, wire a sentinel-bucket cleaner into the existing `clearModuleCache()` — already called from `runInPool.ts` on every `isolate: false` teardown. Context-keyed buckets are WeakMap-held and released with the context itself, so no explicit clearing is needed for those. Local repro loop: with this change and `RSTEST_E2E_MAX_WORKERS=2`, 17 consecutive runs produced zero worker signal exits (baseline reliably crashed within 7–9 runs).

dp

1 month ago

Latest Branches

N/A

ci(codspeed): split CPU per-PR / memory push-to-main, drop codspeed-macro#1321

9 days ago

5d5c1aa

ci/codspeed-threads-pool

+11%

feat(pool): replace tinypool with self-owned worker pool#1171

1 month ago

708b700

dp

+2%

docs(website): improve rstest feature messaging#1205

1 month ago

d359bc9

9aoy/docs-rstest-feature-list

© 2026 CodSpeed Technology

Home Terms Privacy Docs