--- og_image: "/images/guides/vitest-3-vs-jest-30-2026.webp" title: "Vitest 3 vs Jest 30: Testing in 2026" description: "Vitest 3 and Jest 30 compared: speed benchmarks, configuration, TypeScript support, browser mode, and a step-by-step migration guide for 2026 projects." date: "2026-03-18" author: "PkgPulse Team" tags: ["vitest", "jest", "testing", "javascript", "typescript", "comparison", "2026"] --- The JavaScript testing landscape consolidated hard in 2025-2026. Vitest 3 shipped with a redesigned public API, inline workspace configuration, and a mature browser mode backed by Playwright and WebdriverIO. Jest 30 shipped in June 2025 with ESM improvements, a smaller bundle, and dropped Node.js 14/16 support. Both frameworks are production-ready. The question is which one belongs in your stack. The short answer: Vitest is faster, integrates natively with Vite, and has better TypeScript DX. Jest still makes sense if you're on a CommonJS-only codebase, already invested in Jest's snapshot format and mocking patterns, or running a very large test suite where you've tuned Jest's sharding. ## TL;DR **New Vite/TypeScript projects:** Vitest — 5.6x faster cold starts, native ESM, no config required for TypeScript. **Existing Jest codebases:** Migrate when Vitest's speed savings justify the one-time migration cost (usually 1-3 days). **Legacy CommonJS projects:** Jest 30 is safe, maintained, and faster than Jest 29. ## Key Takeaways - **Vitest 3**: 5.6x faster cold starts (38s vs 214s), 28x faster watch mode re-runs (0.3s vs 8.4s), 57% lower peak memory - **Jest 30**: Drops Node 14/16/19/21, ESM wrapper support, jsdom 26, bundled packages for faster startup, `.mts`/`.cts` module extensions - **API compatibility**: Vitest is ~95% API-compatible with Jest — `describe`, `it`, `expect`, `vi.mock` mirrors `jest.mock` - **Migration cost**: Most projects migrate in 1-3 days; the main hurdles are `jest.mock()` factory patterns and manual mocks - **Browser mode**: Vitest 3 has stable browser mode with Playwright/WebdriverIO; Jest uses jsdom (not a real browser) ## At a Glance | | Vitest 3 | Jest 30 | |---|---|---| | Cold start (500 tests) | ~38s | ~214s | | Watch mode re-run | ~0.3s | ~8.4s | | Peak memory | ~400MB | ~930MB | | Native ESM | Yes | Partial (wrappers) | | TypeScript | Native via Vite | Requires ts-jest or babel | | Browser mode | Playwright/WebdriverIO | jsdom only | | Inline workspace config | Yes (projects array) | No | | Snapshot format | Compatible with Jest | Jest format | ## Vitest 3: What's New Vitest 3 shipped in early 2025 and the 3.x series through early 2026 has focused on API stability, browser mode maturity, and monorepo support. ### Inline Workspace Configuration In Vitest 2.x, monorepo projects needed a separate `vitest.workspace.ts` file to define test projects. Vitest 3 deprecated the standalone workspace file in favor of an inline `projects` array in your root `vitest.config.ts`: ```typescript // vitest.config.ts import { defineConfig } from 'vitest/config' export default defineConfig({ test: { projects: [ './packages/*/vitest.config.ts', { test: { name: 'unit', environment: 'node', include: ['**/*.unit.test.ts'], }, }, { test: { name: 'browser', browser: { enabled: true, provider: 'playwright', instances: [{ browser: 'chromium' }], }, include: ['**/*.browser.test.ts'], }, }, ], }, }) ``` The `workspace` terminology was also deprecated because it conflicts with PNPM's workspace concept, which confused developers working in monorepos. ### Browser Mode Vitest 3's browser mode runs tests in a real browser instance via Playwright or WebdriverIO, using a single Vite server to serve all files. This is architecturally different from Jest's jsdom — jsdom simulates the DOM in Node.js, which means CSS, layout, animations, and browser-specific APIs like `IntersectionObserver` require mocking. Vitest's browser mode runs in Chromium, Firefox, or WebKit with no simulation layer. The caching improvement in browser mode is significant: Vitest creates one Vite server regardless of how many browser instances are configured. Files are processed once and reused, making large browser test suites dramatically faster than running isolated jsdom tests per file. ### Redesigned Public API Vitest 3 redesigned `vitest/node` to expose a stable programmatic API for running tests from scripts, CI orchestration tools, or custom test runners. All methods are now documented and versioned: ```typescript import { startVitest } from 'vitest/node' const vitest = await startVitest('test', [], { reporter: 'verbose', coverage: { enabled: true }, }) await vitest.close() ``` ### Annotation API Tests can now attach metadata to test runs: ```typescript import { test, annotate } from 'vitest' test('processes payment', async ({ annotate }) => { await annotate('payment-id', '12345') // visible in HTML reporter, JUnit, GitHub Actions reporter }) ``` ### Filter by Line Number Running a specific test by file and line: ```bash vitest run src/utils.test.ts:42 ``` This speeds up the feedback loop when debugging a single failing test without needing to remember the exact test name. ## Jest 30: What's New Jest 30 shipped June 2025 as the first major release since Jest 29 in 2022. The theme is modernization: drop old Node.js versions, improve ESM support, reduce memory usage. ### Dropped Node.js Versions Jest 30 requires Node.js 18+. Versions 14, 16, 19, and 21 are no longer supported. For teams on Node.js 18 LTS (maintenance mode) or 20/22/24 LTS, this has no impact. For teams still running Node.js 16, upgrading Node.js is now a prerequisite. ### ESM Improvements Jest 30 adds ESM wrappers to its own packages, laying groundwork for Jest itself to run in an ESM context. The new `moduleFileExtensions` now includes `.mts` and `.cts` by default, so TypeScript ESM modules are recognized without manual configuration. `import.meta.*` and `file://` URLs now work when using native ESM with Jest. Note: Jest's ESM support still requires either `--experimental-vm-modules` in Node.js or Babel transform. It's improved but not as seamless as Vitest's native ESM execution. ### Bundled Packages Jest 30 bundles each package into a single file. This reduces `require()` calls during Jest's own startup, producing noticeable cold start improvements. Large test suites that previously waited 8-10 seconds before the first test ran now start in 4-6 seconds. ### jsdom 26 `jest-environment-jsdom` upgrades from jsdom 21 to 26. jsdom 26 adds better Web Crypto support, improved `fetch` compatibility, and fixes for several edge cases in form element handling. Teams using `jest-environment-jsdom` for React component tests get these fixes without code changes. ### Breaking Changes Summary ``` - Node 14, 16, 19, 21 no longer supported - Minimum TypeScript: 5.4 - jest-environment-jsdom: jsdom 21 → 26 - Non-enumerable object properties excluded from toEqual by default - --testPathPattern renamed to --testPathPatterns (plural) - Removed expect aliases: toBeCalled, toBeCalledWith, toBeCalledTimes, etc. (use toHaveBeenCalled, toHaveBeenCalledWith, toHaveBeenCalledTimes) - Jest internals no longer accessible from node_modules ``` ## Speed Comparison The performance gap between Vitest and Jest is architectural, not incidental. Understanding why helps set realistic expectations. ### Why Vitest is Faster Vitest uses Vite's module graph to track import relationships. When you change `utils/date.ts`, Vitest knows exactly which test files import it (transitively) and reruns only those. Jest's `--onlyChanged` uses git diff heuristics, which is less precise and causes more unnecessary reruns. For transforms, Vitest uses esbuild (via Vite) to compile TypeScript and JSX. esbuild compiles TypeScript 10-100x faster than `tsc`. Jest's `ts-jest` uses the TypeScript compiler, and even `babel-jest` is slower than esbuild for large files. ### Benchmark Numbers From production monorepo testing (real-world, not synthetic): **Cold start** (500 test files, TypeScript, React components): - Vitest 3: ~38 seconds - Jest 30: ~214 seconds - Speedup: **5.6x** **Watch mode re-run** (change one utility function, 3 affected test files): - Vitest 3: ~0.3 seconds - Jest 30: ~8.4 seconds (full git-diff-based reruns) - Speedup: **28x** **Memory** (peak during full suite run): - Vitest 3: ~400MB - Jest 30: ~930MB - Reduction: **57%** For small projects with under 100 tests, the difference is less noticeable (both complete in seconds). The gap compounds with project size. ## Configuration Comparison ### Vitest ```typescript // vitest.config.ts import { defineConfig } from 'vitest/config' import react from '@vitejs/plugin-react' export default defineConfig({ plugins: [react()], test: { environment: 'jsdom', globals: true, setupFiles: ['./src/test/setup.ts'], coverage: { provider: 'v8', reporter: ['text', 'html'], include: ['src/**/*.{ts,tsx}'], exclude: ['src/**/*.d.ts'], }, }, }) ``` No separate TypeScript config for tests. No `transform` configuration. Vitest reuses your existing `vite.config.ts` plugins automatically if you don't create a separate `vitest.config.ts`. ### Jest 30 ```javascript // jest.config.js /** @type {import('jest').Config} */ module.exports = { testEnvironment: 'jsdom', transform: { '^.+\\.(ts|tsx)$': ['ts-jest', { tsconfig: './tsconfig.test.json' }], }, moduleNameMapper: { '^@/(.*)$': '/src/$1', '\\.(css|scss)$': 'identity-obj-proxy', }, setupFilesAfterFramework: ['./src/test/setup.ts'], collectCoverageFrom: ['src/**/*.{ts,tsx}', '!src/**/*.d.ts'], coverageReporters: ['text', 'html'], } ``` Jest requires explicit transform configuration for TypeScript. CSS and asset imports need manual mocking via `moduleNameMapper`. Path aliases must be duplicated from `tsconfig.json` into `moduleNameMapper`. ## Mocking Comparison ### Vitest ```typescript import { vi, describe, it, expect, beforeEach } from 'vitest' import { fetchUser } from '../api' vi.mock('../api', () => ({ fetchUser: vi.fn(), })) describe('UserProfile', () => { beforeEach(() => { vi.mocked(fetchUser).mockResolvedValue({ id: '1', name: 'Alice' }) }) it('renders user name', async () => { // ... }) }) ``` ### Jest 30 ```typescript import { jest, describe, it, expect, beforeEach } from '@jest/globals' import { fetchUser } from '../api' jest.mock('../api', () => ({ fetchUser: jest.fn(), })) describe('UserProfile', () => { beforeEach(() => { jest.mocked(fetchUser).mockResolvedValue({ id: '1', name: 'Alice' }) }) it('renders user name', async () => { // ... }) }) ``` The APIs are nearly identical. The main difference is `vi` vs `jest`. Vitest's `vi` object has the same surface area as Jest's `jest` object. ## Migration Guide: Jest → Vitest Most migrations complete in 1-3 days. Here's the systematic approach. ### Step 1: Install Vitest ```bash npm install -D vitest @vitest/coverage-v8 # If using React: npm install -D @vitejs/plugin-react jsdom # If using browser mode: npm install -D @vitest/browser playwright ``` ### Step 2: Create vitest.config.ts ```typescript import { defineConfig } from 'vitest/config' import react from '@vitejs/plugin-react' export default defineConfig({ plugins: [react()], test: { globals: true, // Makes describe/it/expect available without imports environment: 'jsdom', setupFiles: ['./src/setupTests.ts'], }, }) ``` ### Step 3: Update package.json Scripts ```json { "scripts": { "test": "vitest run", "test:watch": "vitest", "test:coverage": "vitest run --coverage" } } ``` ### Step 4: Replace jest Imports ```bash # Find all files importing from jest grep -r "from '@jest/globals'" src/ --include="*.ts" -l # Replace jest global with vi # jest.fn() → vi.fn() # jest.mock() → vi.mock() # jest.spyOn() → vi.spyOn() # jest.clearAllMocks() → vi.clearAllMocks() ``` If you use `globals: true` in vitest.config.ts, you don't need to import `describe`, `it`, `expect` — they're automatically available, just like Jest's default behavior. ### Step 5: Fix jest.mock() Factory Issues The most common migration issue: Vitest hoists `vi.mock()` calls to the top of the file (like Jest does), but the factory function cannot reference variables defined in the module scope. This is the same constraint as Jest but some codebases rely on patterns that technically work in Jest due to implementation differences. ```typescript // This may fail in Vitest: const mockUser = { id: '1', name: 'Alice' } vi.mock('../api', () => ({ fetchUser: vi.fn().mockReturnValue(mockUser) })) // Fix: use vi.mocked() in beforeEach instead vi.mock('../api') beforeEach(() => { vi.mocked(fetchUser).mockReturnValue({ id: '1', name: 'Alice' }) }) ``` ### Step 6: Update Snapshot Files Vitest's snapshot format is identical to Jest's. Existing `.snap` files work without changes. If you have inline snapshots using `toMatchInlineSnapshot`, those also work as-is. ## TypeScript Support Vitest has native TypeScript support through Vite's esbuild pipeline. You get type checking in your editor for test code without additional packages. Type inference works across mock implementations, `vi.mocked()` returns properly typed mocks, and test utilities like `expect.extend()` are fully typed. Jest 30 requires `ts-jest` or `@babel/preset-typescript`. `ts-jest` performs full type-checking during tests (slower but catches type errors). `babel-jest` strips types without checking them (faster but misses type errors). Neither is as ergonomic as Vitest's zero-config TypeScript. ## Snapshot Testing Both frameworks use the same snapshot format. The workflow is identical: ```typescript it('renders correctly', () => { const { asFragment } = render() expect(asFragment()).toMatchSnapshot() }) ``` Update snapshots: `vitest run --update-snapshots` or `jest --updateSnapshot`. ## Coverage Vitest supports two coverage providers: `v8` (native V8 coverage, fast, zero config) and `istanbul` (same as Jest, more accurate for some edge cases). Jest uses istanbul exclusively. For most projects, Vitest's `v8` coverage is sufficient and meaningfully faster. If you need the exact same coverage numbers as Jest for compliance reporting, use `@vitest/coverage-istanbul`. ## When to Stick with Jest - **CommonJS-only environment**: If you can't adopt ESM, Jest 30 handles CJS more smoothly - **Very large test suites with sharding**: Jest's `--shard` implementation is more mature; Vitest added sharding in v1 but Jest's is more battle-tested for 10K+ test suites - **Team already productive in Jest**: Migration has a cost; if your tests pass and CI times are acceptable, there's no emergency - **Angular projects**: Angular's testing ecosystem is built around Jest and Jasmine; Vitest works but the ecosystem support is thinner ## CI/CD Integration Running tests in CI is where configuration differences between Vitest and Jest become most visible. Both support parallelization and sharding, but their approaches differ in practical ways. ### GitHub Actions: Vitest ```yaml # .github/workflows/test.yml name: Test on: [push, pull_request] jobs: test: runs-on: ubuntu-latest strategy: matrix: shard: [1, 2, 3, 4] steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 cache: npm - run: npm ci - run: npx vitest run --shard=${{ matrix.shard }}/4 --reporter=junit --outputFile=test-results/junit-${{ matrix.shard }}.xml - uses: actions/upload-artifact@v4 if: always() with: name: test-results-${{ matrix.shard }} path: test-results/ ``` Vitest's `--shard=N/M` flag splits the test suite into M shards and runs shard N. The matrix strategy runs all shards in parallel, reducing total CI time proportionally. A 4-shard setup for a 500-test suite cuts a 38-second run down to approximately 10-12 seconds wall time. ### GitHub Actions: Jest 30 ```yaml name: Test on: [push, pull_request] jobs: test: runs-on: ubuntu-latest strategy: matrix: shard: [1, 2, 3, 4] steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 cache: npm - run: npm ci - run: npx jest --shard=${{ matrix.shard }}/4 --ci --forceExit --reporters=default --reporters=jest-junit env: JEST_JUNIT_OUTPUT_DIR: test-results JEST_JUNIT_OUTPUT_NAME: junit-${{ matrix.shard }}.xml - uses: actions/upload-artifact@v4 if: always() with: name: test-results-${{ matrix.shard }} path: test-results/ ``` Jest requires `--ci` to disable interactive watch mode in CI environments and `--forceExit` to terminate the process after tests complete (Jest sometimes hangs waiting for open handles). The `jest-junit` package must be installed separately for JUnit output; Vitest includes JUnit as a built-in reporter. ### Parallelization Strategy Both frameworks run test files in parallel by default using worker threads. Key configuration options: **Vitest:** ```typescript // vitest.config.ts export default defineConfig({ test: { pool: 'threads', // 'threads' (default) | 'forks' | 'vmThreads' poolOptions: { threads: { maxThreads: 4, // Cap workers (useful in memory-constrained CI) minThreads: 2, }, }, fileParallelism: true, // Run files in parallel (default: true) isolate: true, // Fresh module registry per file (default: true) }, }) ``` **Jest 30:** ```javascript // jest.config.js module.exports = { maxWorkers: '50%', // Use 50% of available CPUs (default in CI) workerThreads: true, // Use worker_threads instead of child_process (Jest 29+) testTimeout: 10000, forceExit: true, // Prevents CI hangs from open handles } ``` Vitest's `pool: 'vmThreads'` option uses V8 context isolation (lighter than full worker threads), which reduces memory usage at the cost of slightly less isolation. This is useful for memory-constrained CI runners where `--max-old-space-size` limits apply. ### Coverage in CI For projects that enforce coverage thresholds in CI, both frameworks support failing the build when thresholds aren't met: ```typescript // vitest.config.ts export default defineConfig({ test: { coverage: { provider: 'v8', thresholds: { lines: 80, functions: 80, branches: 70, statements: 80, }, reporter: ['text', 'lcov'], // lcov for Codecov/Coveralls upload }, }, }) ``` ```javascript // jest.config.js module.exports = { coverageThreshold: { global: { lines: 80, functions: 80, branches: 70, statements: 80, }, }, coverageReporters: ['text', 'lcov'], } ``` Both exit with a non-zero code when thresholds aren't met, failing the CI run. Vitest's v8 coverage generates these reports 2-3x faster than Jest's istanbul, which matters for large codebases that run coverage on every PR. ## Related Articles - [Bun Test vs Vitest vs Jest 2026](/guides/bun-test-vs-vitest-vs-jest-test-runner-benchmark-2026) - [Best JavaScript Testing Frameworks 2026](/guides/best-javascript-testing-frameworks-2026) - [Bun 2.0 vs Node.js 24 vs Deno 3 in 2026](/guides/bun-2-vs-nodejs-24-vs-deno-3-2026)