Jest: babel-jest transforms your files behind your back, and Vite is only partly supported

babel-jest transforms every file as soon as a Babel config exists

The default is invisible until it surprises you. `babel-jest` is installed automatically when you install Jest, and it will automatically transform files if a Babel configuration exists in your project. There is no flag to turn that on.

The way out is documented, and it is a reset rather than a setting:

// jest.config.js
module.exports = {
  transform: {},
};

That empty object disables the behaviour. So the sequence a reader should expect is: add Jest, discover that your application's Babel config is now in charge of how test files are compiled, and either accept that or reset the transform.

The consequence is that a Babel config written for production bundling becomes a test config by accident. A preset that targets browsers will compile for the test run too, and a plugin that injects code into modules will do it under test as well. The README is explicit that the ideal Babel configuration depends on your project and points at Babel's own documentation for the details, which is another way of saying the answer is not the same for everyone.

Jest sets NODE_ENV to test, and that is also your hook for a Babel config

Jest sets `process.env.NODE_ENV` to `'test'` if it is not set to something else, and the documented use for that is a Babel config that only sets up what the tests need. The shape given is a function rather than an object:

// babel.config.js
module.exports = api => {
  const isTest = api.env('test');
  // You can use isTest to determine what presets and plugins to use.

  return {
    // ...
  };
};

So one Babel config serves two consumers, the bundler and the test runner, and the environment variable is what tells them apart. The value Jest writes is only a default: if something already set NODE_ENV to another value, Jest leaves it alone, which means a wrapper script that exports NODE_ENV=production before running tests will silently change which Babel branch you get.

The consequence is that the `isTest` branch is a second code path you have to write and keep working, and a mistake in it produces tests that run against a different build of your code than the one you ship.

Vite is called out as not fully supported, in the setup guide itself

The bundler sections of the README are uneven on purpose, and the Vite one is the odd one out. webpack gets a sentence about unique challenges and a link. Parcel gets a sentence and the note that it requires zero configuration. Vite gets a paragraph that says Jest is not fully supported by Vite due to how the Vite plugin system works, that there are some working examples of first class Jest integration using `vite-jest`, and that since this is not fully supported you might as well read the limitations of `vite-jest`.

That is a candid admission in a project's own getting started page, and the link goes to a third party repository's limitations page, not to Jest's own.

The consequence is practical. A team whose bundler is Vite is being told, in the setup instructions, to go read a third party plugin's caveats before starting. Nothing says it will not work, and the Vite guide link is right there, but the asymmetry with webpack and Parcel is the signal: this is a supported-if-you-do-work path rather than a first class one. A reader choosing a test runner for a Vite codebase should read that limitations page before writing the first test, not after.

Jest can run from a global install, and one command shows all three input styles

The command line section assumes you may not have a local install. You can run Jest directly from the CLI if it is globally available in your PATH, for example through `yarn global add jest` or `npm install jest --global`. The worked example then combines the three ways you can shape a run:

jest my-test --notify --config=config.json

A positional pattern picks the files, `--config` names a configuration file other than the one Jest would find, and `--notify` asks for a native OS notification after the run. The full option list lives on the CLI options page rather than in the README, which is the pattern for the whole document.

If you would rather not write a config by hand, `yarn create jest` asks a few questions based on your project and writes a basic configuration file with a short description for each option. The consequence is two ways to arrive at a config, and they can disagree: a generated one, and one you edited. The descriptions in the generated file are comments, not documentation you can look up later, so a config produced that way tends to become an unread config as soon as the comments age.

TypeScript is supported through Babel, so types are erased rather than checked

The TypeScript section is short because it adds nothing new: Jest supports TypeScript via Babel. The instruction is to follow the Babel instructions first, then install the preset, `yarn add --dev @babel/preset-typescript`, and then reference it in the Babel config.

There is no type checking anywhere in that path, and there is no second tool in the instructions that would do it. Babel strips the types and produces JavaScript for Jest to run, and a type error in your test file is not a test failure.

The consequence is that a green Jest run says nothing about whether the types are correct, which matters more in a TypeScript codebase than it does elsewhere, and it matters most in the places people forget: test files themselves, where a mistyped mock or a wrong assertion argument passes unnoticed. If your project relies on types as a correctness check, that check has to run as a separate step, and the README does not tell you what it is. The repository itself is a good hint at the answer, because the top level carries `tsconfig.json`, `tsconfig.test.json`, `tsconfig.typetest.json` and `tstyche.json`.

Three jest config files and a changelog that splits at v30

The top level of the repository is more informative than the README about how the project is put together. There are three Jest configuration files: `jest.config.mjs`, `jest.config.ci.mjs` and `jest.config.ts.mjs`, so the local run, continuous integration and the TypeScript case are configured separately rather than sharing one file with conditionals.

The changelog is split as well. `CHANGELOG.md` and `CHANGELOG_PRE_v30.md` sit side by side, which tells you that the v30 boundary was treated as a line worth separating history on. The release list matches that line: v30.5.2 on 2026-09-18, v30.5.1 on 2026-09-01 and v30.5.0 on 2026-08-28, all patch level, and the last push to the default branch, main, was on 2026-09-27.

The package manifest is the root workspace, named `@jest/monorepo`, marked private, with its version pinned at 0.0.0 and internal packages referenced as `workspace:*`. So the version a user installs and the version in this file are different things by design, and a reader chasing a behaviour change should look at the tag rather than at the manifest.

Fourteen example directories, three of them about how mocking works

The `examples/` directory is the real reference for what Jest does, and its fourteen entries divide into three groups. Feature examples cover angular, async, expect-extend, getting-started, jquery, react, react-native, react-testing-library, snapshot, timer and typescript. Framework and tool examples cover the bundlers, and then there are three that are purely about substitution: automatic-mocks, manual-mocks and module-mock.

That third group is the one to read before designing a test. The difference between a mock Jest creates for you and one you write by hand is the difference between a test that breaks when someone adds a method to a dependency and one that keeps passing while silently exercising the wrong thing, and having all three directories side by side is the clearest way to see the three positions available.

The consequence for a reader is that the examples, not the prose, are where the decisions live. The README's own framing is a three line pitch, developer ready, instant feedback through a watch mode that only runs test files related to changed files, and snapshot testing for large objects, with everything else deferred to jestjs.io. A team choosing a test runner should read a directory or two from `examples/` before reading a single documentation page.

Editorial conclusion

Jest fits a JavaScript or TypeScript codebase that wants snapshots, a watch mode and a zero-configuration start, and it is a poor fit for a Vite project that expects first class support from the bundler it already uses. Before you commit, check whether a Babel config is present in the repository, because babel-jest will pick it up and transform your files whether you asked it to or not, and read the Vite section if vite is your tool. Pin a v30 release, and expect the documentation to be written in yarn commands even when you use npm.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes