npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

rjest-rust-runner

v0.1.0-alpha.1

Published

Rust-powered, Jest-compatible test runner with a native coordinator

Readme

Rjest: a Rust-powered Jest-compatible test runner

JavaScript and TypeScript testing without rewriting your Jest suite

Keep your tests. Change the engine. Measure the difference.

Website · Benchmarks: 3 measured wins, 1 known loss · Project status: ≈91% directional readiness · Compatibility · Migration guide · Architecture

Status: alpha npm alpha Jest differential: 286/286 Measured discovery: 3.95x faster Readiness: about 91% Coordinator: Rust Runtime: Node 22.18+ License: MIT GitHub stars

- npx jest
+ npx rjest

That is the goal.

Rjest is built on a stubborn premise: a Jest alternative is only useful if it runs the Jest suite you already have. Rewriting years of tests, snapshots, mocks, transforms, and configuration is not a migration. It is a new project.

Rjest keeps JavaScript execution in isolated Node workers and moves discovery, scheduling, dependency analysis, process control, coverage aggregation, and reporting into Rust. Every compatibility claim must survive the same fixture under official Jest and Rjest.

That split is already measurable. In a controlled Apple M2 comparison, Rjest was 1.59× faster at cold start, 2.86× faster across 50,000 assertions, and 3.95× faster listing 1,500 test files. It was also 2.83× slower on a 48-file workload because fresh workers are not reused yet. The wins and the loss come from the same ten-run report.

Alpha status: Rjest already runs substantial React, TypeScript, Node, JSDOM, CommonJS, ESM, snapshot, mock, fake-timer, coverage, and monorepo suites. It does not cover the entire Jest surface yet. Keep Jest as your release gate and compare both runners before adopting the alpha.

Read the honest project status: what ≈91% means, what is proven automatically, and what remains before a universal drop-in claim would be justified.

The short version

| What you probably want to know | Verified answer | | ---------------------------------------------------------------- | -------------------------------------------------- | | Does it use existing Jest tests? | Yes, across the measured surface | | Does it read Jest configuration? | Yes, with explicit errors for unsupported options | | Are snapshots, mocks, timers, ESM, JSDOM, and coverage included? | Yes, within the documented boundaries | | Is compatibility measured against official Jest? | 286 / 286 executable scenarios pass | | Has it run serious public projects? | 25 pinned corpus reports | | Is it production-ready everywhere? | No. Current directional readiness is about 91% | | Is it already faster than Jest? | On 3 controlled workloads; slower on many files |

Rust speed, with receipts

Rjest was rebuilt to make the coordination layer native: startup, discovery, selection, scheduling, aggregation, and reporting no longer need to live inside the JavaScript runner. The first controlled benchmark shows where that decision already pays off—and where it does not.

| Apple M2 · caches off · 10 measured pairs | Jest median | Rjest median | Rjest vs Jest | | ----------------------------------------- | ----------: | -----------: | ---------------: | | Cold start · 1 file, 1 assertion | 737.2 ms | 462.9 ms | 1.59× faster | | Assertion throughput · 50,000 assertions | 2.19 s | 764.4 ms | 2.86× faster | | Discovery · list 1,500 files | 727.5 ms | 184.0 ms | 3.95× faster | | Many files · 48 files, 4 workers | 1.92 s | 5.43 s | 2.83× slower |

Both runners first had to match the expected result or discovered path set. Every command, version, raw sample, median, variance, and memory observation is in the full performance report and raw JSON. These are measurements for named workloads, not a universal speed claim.

Compatibility with receipts

Rjest does not award itself points for having a familiar method name. The differential harness runs a fixture with pinned official Jest, runs it again with Rjest, normalizes observable behavior, and compares the results. A fixed mismatch stays in the repository as a regression test.

Jest 30.5.0 is the default oracle. One snapshot-format probe intentionally uses Jest 29.7.0.

| Area | Passing | Measured score | | -------------------- | ------------: | -------------: | | CLI | 76 / 76 | 100% | | Configuration | 58 / 58 | 100% | | Core API | 16 / 16 | 100% | | Coverage | 19 / 19 | 100% | | Environment | 7 / 7 | 100% | | ESM | 8 / 8 | 100% | | Expect | 19 / 19 | 100% | | Fake timers | 20 / 20 | 100% | | Mocks | 17 / 17 | 100% | | Reporters | 7 / 7 | 100% | | Resolution | 12 / 12 | 100% | | Snapshots | 16 / 16 | 100% | | Transforms | 7 / 7 | 100% | | Watch | 4 / 4 | 100% | | Versioned matrix | 286 / 286 | 100% |

The 100% above means every scenario currently in the versioned matrix passes. It does not mean Rjest implements 100% of Jest. The matrix is deliberately bounded, inspectable, and expected to grow. Read every measured scenario.

Real Jest projects, unchanged

Synthetic fixtures are necessary. They are not enough. Rjest also runs the original tests and configuration from established open-source projects.

| Project suite | Official Jest baseline | Rjest result | | ------------------------------------------------------------- | --------------------------------------------: | ------------------------------------------------------: | | Downshift | 92 suites · 1,110 tests · 49 snapshots | Exact parity | | React Testing Library | 16 suites · 251 tests · 11 snapshots | Exact React 19/JSDOM parity | | styled-components web | 59 suites · 1,465 tests · 749 snapshots | Exact parity | | React Navigation | 81 suites · 1,303 identities · 169 snapshots | Exact parity, including the same 2 upstream failures | | AWS Amplify Auth | 101 suites · 1,150 tests | Exact identity, status, and coverage parity | | Apollo Client | 563 suites · 9,974 identities · 519 snapshots | 99.940% frozen-status parity · zero Rjest-only failures |

The complete corpus spans React, React Native, TypeScript, Node, JSDOM, CommonJS, native ESM, npm, pnpm, Yarn workspaces, and Yarn Plug'n'Play. There are 25 pinned reports, including commands, versions, results, timings, and memory where practical.

Try Rjest on an existing suite

Install the current alpha as a development dependency:

npm install --save-dev rjest-rust-runner@alpha

The alpha compiles its native coordinator for your machine during installation, so it currently requires Node.js 22.18 or newer and Rust 1.85 or newer.

Start in an existing Jest project with the lowest-risk comparison:

cd /path/to/your-jest-project

# Compare discovery first
npx rjest --listTests

# Then compare a deterministic serial run
npx rjest --runInBand

# Finally, let Rjest schedule files in parallel
npx rjest

If both runners disagree, reduce the mismatch to one fixture and open an issue. That report is more useful than a broad request for "more Jest support."

Familiar Jest commands

rjest --coverage
rjest --updateSnapshot
rjest --testNamePattern=calculator
rjest --testRunner=jest-circus/runner
rjest --maxWorkers=50%
rjest --projects packages/api packages/web
rjest --selectProjects web --ignoreProjects legacy
rjest --shard=1/3
rjest --randomize --seed=1234
rjest --onlyFailures
rjest --findRelatedTests src/parser.ts src/config.ts
rjest --watch
rjest --watchAll
rjest --forceExit --no-coverage
rjest --no-cache
rjest --clearCache

Unsupported configuration is an error. Rjest will not silently ignore a Jest option and return a reassuring but incomplete test run.

What works today

Tests, assertions, and mocks

  • describe, test, it, nested hooks, async and callback tests, .only, .skip, .todo, .failing, retries, bail, sharding, and seeded randomization
  • Jest equality, common and asymmetric matchers, custom async matchers, .resolves, .rejects, assertion counts, expect.arrayOf, expect.closeTo, and mock return-history matchers
  • jest.fn, argument-routed whenCalledWith branches, spies, property replacement, CommonJS and native-ESM mocks, manual mocks, automocking, module resets, restoration, and mock generation hooks

JavaScript, TypeScript, and project configuration

  • JavaScript, configured JSX/TypeScript/TSX transforms, CommonJS, native ESM, top-level await, Node, JSDOM, and custom test environments
  • Executable JS/TS configuration, presets, multi-project runs, display-name filters, explicit Jest Circus selection, custom resolvers, custom sequencers, pnpm, and Yarn Plug'n'Play
  • CommonJS, ESM, and transformed TypeScript global setup/teardown, custom reporters, and test-results processors

Snapshots, fake timers, coverage, and watch mode

  • External and inline snapshots, property matchers, serializers, update mode, obsolete detection, Prettier 2/3, and source-mapped inline writes
  • Modern and legacy fake timers across measured Node and JSDOM boundaries, including Jest 30 manual, next-async, and interval tick modes
  • Babel/Istanbul and V8 coverage, cross-worker merging, source maps, collectCoverageFrom, common reports, and scoped thresholds
  • Native filesystem watching, Git-aware affected-test selection, interactive TTY controls, and interruption of active parallel workers

The exact boundary is documented in Jest compatibility.

Why Rust and Node?

01 RUST / PLAN          02 NODE / RUN           03 RUST / REPORT
config + discovery  ->  isolated test workers  ->  results + snapshots + coverage

Rust owns coordination: filesystem scans, configuration normalization, dependency graphs, scheduling, worker lifecycles, aggregation, coverage merging, and snapshot persistence. That native boundary is why controlled discovery is already 3.95× faster and cold start is 1.59× faster on the published Apple M2 workload.

Node owns JavaScript semantics: module loading, Jest transformers, custom environments, runtime extensions, and the test code itself.

Each test file currently gets a fresh worker process. Isolation is strong and aggregation stays deterministic, but startup cost is real. Worker reuse and persistent transform/discovery caches remain open work. The architectural reasoning starts in ADR 0001.

The honest performance boundary

Rjest does not turn one favorable microbenchmark into “faster than Jest.” The same report that shows three wins records a 2.83× regression across 48 small files. Each file currently pays for a fresh Node process, so worker reuse and persistent transform caches are the next major performance target.

A runner that skips behavior does not get to call itself fast. Benchmark timing starts only after Jest and Rjest match the expected suite result or discovery set. Read the benchmark method and publication policy.

Honest alpha boundaries

The current project-readiness estimate is approximately 91%. This is a directional engineering estimate, not an automated percentage of the Jest API. The automated number is the 286-scenario matrix above. The distinction and the remaining work are recorded in the project status.

  • Watch plugins, Mercurial/Sapling changed-file selection, and some terminal output details remain open.
  • Transform and discovery caches are not persisted, and workers are not reused.
  • Exact custom-environment VM identity, specialized reporter built-ins, and long-tail resolver/PnP combinations need broader proof.
  • Basic TypeScript can use Node's erasable syntax. TSX and TypeScript that needs code generation still require a configured Jest transformer.
  • Unlisted behavior is not a compatibility claim, even when it happens to work.

Before using Rjest as a release gate, read the migration guide.

Verify the evidence

make check

That command runs Rust formatting, strict Clippy, all workspace tests, JavaScript syntax and comparator tests, and every differential fixture against the pinned official Jest oracles. The current local Rust suite is 133/133, and the generated compatibility matrix is 286/286.

Help close the next gap

The most useful contribution is one small proof that Jest and Rjest disagree:

  1. Reproduce it with official Jest.
  2. Add the smallest differential fixture that captures the behavior.
  3. Fix Rjest without weakening the fixture.
  4. Keep the regression forever.

Open an issue · Read the development guide · See current progress

If the idea of a compatibility-first Jest alternative makes sense to you, star Rjest and try one real suite. One precise mismatch is enough to move the project forward.

Project map

License

MIT. Rjest is an independent project. Jest attribution is recorded in NOTICE.md.