Should I pick Jest or Vitest for a new project?

Vitest is usually the simpler choice for projects already built on Vite (it reuses the same config and transform pipeline and runs TypeScript/ESM natively without extra setup), while Jest remains the safer choice for established codebases, projects relying on its large plugin/matcher ecosystem, or setups like Create React App / Next.js that documented Jest first. Both run the same describe/it/expect API, so switching later mainly means re-running this generator, not rewriting tests.

Why does "globals" behave differently between the two outputs?

Jest injects describe/it/expect as ambient globals by default, so this tool only emits injectGlobals: false when you turn globals off; there's nothing to add when it's on. Vitest defaults to NOT injecting globals (favoring explicit imports from "vitest"), so it needs an explicit test.globals: true/false written into the config either way.

What's the difference between coverage providers v8 and istanbul?

v8 uses Node's built-in V8 coverage counters, it's faster and needs no extra instrumentation step, and is the modern default for both Jest and Vitest. istanbul instruments the code before running it, which is slower but has historically produced more precise line/branch coverage in some edge cases; most projects can default to v8 and only switch to istanbul if they hit a specific accuracy issue.

Why does the alias mapping look different in the Jest output vs. the Vitest output?

Jest resolves module aliases via moduleNameMapper, a regex-keyed object (this tool writes each alias as a `"^alias/(.*)$": " /path/$1"` regex/replacement pair), because Jest's module resolution is its own implementation. Vitest instead reuses Vite's resolver, so aliases go under resolve.alias as plain string-to-path pairs, matching the same shape you'd use in a vite.config.ts.

Jest/Vitest Config Generator - jest.config.js or vitest.config.ts

Overview

Introduction

Jest and Vitest both run the same describe/it/expect testing API, but their config files use different shapes for the same underlying concepts, coverage provider, module aliasing, and setup files chief among them, which makes translating a working config from one to the other more fiddly than it should be.

This tool generates either a jest.config.js or a vitest.config.ts from one shared options form, so switching test runners (or supporting both during a migration) doesn't mean re-learning each tool's config schema from scratch.

What Is Jest/Vitest Config Generator?

A test-runner config generator supporting two output flavors, Jest's jest.config.js (CommonJS module.exports) and Vitest's vitest.config.ts (defineConfig from "vitest/config"), from the same underlying options: test environment, TypeScript preset, globals, test-match glob, coverage, setup files, and path aliases.

Handles the two runners' structurally different equivalents for the same feature, Jest's moduleNameMapper regex object vs. Vitest's resolve.alias string map, and Jest's ambient globals default vs. Vitest's explicit test.globals flag, so the generated output is idiomatic for whichever runner is selected.

How Jest/Vitest Config Generator Works

The test-match glob is validated as non-empty, then setup files and aliases are trimmed and empty entries filtered out before being written into either output.

For Jest, the options are serialized into a module.exports object with testEnvironment, testMatch, testPathIgnorePatterns, an optional ts-jest preset, optional injectGlobals: false, setupFilesAfterEnv, moduleNameMapper, and coverage settings.

For Vitest, the same options are serialized into a defineConfig({ test: { ... }, resolve: { alias: { ... } } }) call, with environment, globals, include, setupFiles, and a coverage block using the same provider value.

When To Use Jest/Vitest Config Generator

Use it when setting up a test runner on a new project and you want a config with sane, explicit defaults (testPathIgnorePatterns, a real coverage provider) instead of an empty default export.

It's also useful when migrating a project from Jest to Vitest (or the reverse), since flipping the flavor toggle regenerates the equivalent config from the same option values instead of requiring a manual line-by-line translation.

Often used alongside Babel Config Generator and tsconfig.json Generator.

Features

Advantages

One options form drives two structurally different config shapes, so you don't need to separately learn moduleNameMapper's regex syntax and resolve.alias's plain-string syntax.
Bundles sensible defaults most projects want on day one: testPathIgnorePatterns excluding node_modules/dist, and a modern v8 coverage provider.
Keeps Jest's and Vitest's genuinely different globals defaults correct automatically, rather than requiring the user to know which runner needs an explicit flag.

Limitations

Covers the handful of options most projects configure directly (environment, coverage, aliases, setup files, test match); advanced features like custom reporters, projects/workspaces, or watch-mode plugins aren't exposed and can be hand-added afterward.
The ts-jest preset toggle only applies to the Jest output; Vitest handles TypeScript natively via esbuild and has no equivalent preset to configure.

Examples

Node environment, TypeScript, coverage on, one alias (Jest)

Input

flavor: jest, testEnvironment: node, useTypescript: true, coverageEnabled: true, coverageProvider: v8, aliases: [{ alias: "@/", path: "src/" }]

Output

/** @type {import("jest").Config} */
module.exports = {
  testEnvironment: "node",
  testMatch: ["**/*.test.ts"],
  testPathIgnorePatterns: ["/node_modules/", "/dist/"],
  preset: "ts-jest",
  moduleNameMapper: {
    "^@/(.*)$": "<rootDir>/src/$1",
  },
  collectCoverage: true,
  coverageProvider: "v8",
  coverageDirectory: "coverage",
};

Best Practices & Notes

Best Practices

Default coverage to the v8 provider unless a specific accuracy issue points you to istanbul, it's faster and needs no extra instrumentation step in either runner.
Keep testPathIgnorePatterns excluding build output directories (dist, coverage) so a stray compiled .test.js file doesn't get picked up and run alongside its TypeScript source.
When migrating between Jest and Vitest, regenerate both configs from the same option values with this tool and diff the outputs, rather than hand-translating moduleNameMapper regexes into resolve.alias entries.

Developer Notes

The Jest output intentionally keeps testPathIgnorePatterns as a fixed, always-on default rather than a configurable option, since virtually every project needs node_modules and its build output excluded and almost none want to remove that exclusion. The Vitest alias block only imports "node:path" when at least one alias is configured, keeping the output free of an unused import when aliases are left empty.

Jest/Vitest Config Generator Use Cases

Adding a first test-runner config to a project that has Jest or Vitest installed but no config file yet
Migrating an existing test suite from Jest to Vitest (or vice versa) and needing an equivalent starting config
Standardizing coverage provider and test-match conventions across multiple repositories on a team

Common Mistakes

Forgetting the ts-jest preset when writing TypeScript tests under Jest, which causes Jest to fail parsing .ts files with a cryptic syntax error instead of a clear "missing transform" message.
Copying a Jest moduleNameMapper regex entry directly into a Vitest config's resolve.alias (or vice versa), when the two options expect structurally different values (a regex/replacement pair vs. a plain path string).

Tips

If the project already has a vite.config.ts, prefer the Vitest flavor and merge the generated test block into it rather than keeping two separate config files.
Use the Babel Config Generator alongside the Jest flavor when not using ts-jest, since Jest needs a transform (babel-jest via babel.config.js, or the ts-jest preset) to process non-CommonJS syntax.

Jest/Vitest Config Generator