Skip to content
rjest

← Back home · Compare

rjest vs Jest

The baseline rjest is compatible with

Jest is the contract rjest agrees to. Same matchers, same config files, same CLI flags. The trade is a background daemon for amortized warm runs.

Feature rjest Jest Advantage
Warm-run latency ~14ms in repo benchmark (10-100× depending on suite) ~1.4s on the same suite rjest
Cold start ~1.9s (daemon boot) ~1.4s Jest
Config files jest.config.{js,ts,mjs} + package.json jest.config.{js,ts,mjs} + package.json Comparable
CLI flags --watch, --coverage, --runInBand, --testNamePattern, --json, --machine Same surface (no --machine) Comparable
Matchers / mocks / snapshots Compatible (toBe, toEqual, jest.fn, jest.mock, toMatchSnapshot) Reference implementation Comparable
TypeScript transform SWC native, blake3-keyed sled cache Babel or ts-jest, no persistent cache rjest
Worker model Persistent VM-context workers, warm across runs Forked per invocation rjest
Coverage Istanbul Istanbul Comparable
ESM support Via SWC transform; same caveats as Jest Experimental flag Comparable
Watch mode Daemon FS watcher, deps graph in memory Per-process watcher rjest
Background process required Yes (jestd) No Jest
License MIT MIT Comparable

Pick rjest when

  • Your Jest suite takes more than a few seconds and the team feels it in CI
  • You want the speedup without touching jest.config.* or your transformer chain
  • You run watch mode locally and want sub-second feedback on changes
  • You drive tests from an AI agent and want structured --json or --machine output with low latency

Pick Jest when

  • Your suite already runs in well under a second cold
  • You have a Jest plugin that touches private internals not yet on the compatibility matrix
  • Your environment forbids long-running background processes

Still deciding?

The cheapest validation is to install rjest alongside Jest in CI and compare a few hundred runs. If a test passes in Jest but not rjest, file an issue — we will treat it as a contract violation.