Jest ESM TypeScript Setup: ts-jest, Babel, SWC or Node Type Stripping

Do You Need Native ESM in Jest?

You need native ESM in Jest when Node runs your code as ES modules, or when the code uses syntax that CommonJS cannot express. Jest 30.5's ECMAScript Modules guide still calls its ESM support experimental, so if none of the cases below applies, the CommonJS path is the simpler one to keep.

• Node runs the code as ESM - your package.json sets "type": "module", which TypeScript's compiler options guide asks for when you emit ES modules for Node, and the tests import those modules directly.
• import.meta or top-level await - neither compiles to CommonJS, so a transform that targets CommonJS cannot run that code; the tsc output below shows both errors.
• ESM-only dependencies - a package that ships only ES modules fails in a CommonJS run unless Jest transforms it or loads it as ESM, as the next section shows.

TypeScript 5.9.3 reported both errors when a file with top-level await and a file that reads import.meta.url compiled with "module": "commonjs" (output trimmed and wrapped):

src/config.ts(1,13): error TS1378: Top-level 'await'
expressions are only allowed when the 'module' option is
set to 'es2022', 'esnext', 'system', 'node16', ...
src/paths.ts(1,21): error TS1343: The 'import.meta'
meta-property is only allowed when the '--module' option
is 'es2020', 'es2022', 'esnext', 'system', 'node16', ...

A bundled app can stay on CommonJS in Jest. TypeScript's guide pairs bundler projects with "module": "esnext" and "moduleResolution": "bundler" and recommends not setting "type": "module" in them for now, so ts-jest's default CommonJS preset keeps working. If ESM friction is the reason you are weighing a switch of test runner, the Vitest vs Jest comparison covers that trade-off.

export default {
  transformIgnorePatterns: ['/node_modules/(?!(esm-only-pkg)/)'],
};

Step 1: Turn On ESM Mode in Node and Jest

Jest evaluates ES modules through Node's node:vm module, and Node keeps the ES module part of that API behind a flag: its command-line docs describe --experimental-vm-modules as enabling "experimental ES Module support in the node:vm module". The check below ran on Node 25.5.0 on November 11, 2026 (warning lines wrapped).

import vm from 'node:vm';

console.log(typeof vm.SourceTextModule);
if (vm.SourceTextModule) new vm.SourceTextModule('export {}');

$ node vm-check.mjs
undefined
$ node --experimental-vm-modules vm-check.mjs
function
(node:41892) ExperimentalWarning: VM Modules is an
experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the
warning was created)
$ node --experimental-vm-modules \
    --disable-warning=ExperimentalWarning vm-check.mjs
function

• Without the flag - vm.SourceTextModule is undefined, so Jest's ESM loader has no class to build modules with.
• With the flag - the class exists, and Node prints an ExperimentalWarning the first time a module is created.
• --disable-warning=ExperimentalWarning - hides that line, along with every other experimental-feature warning in the same process.

Put the flag in the test script rather than a shell profile, so local runs, CI and cloud runners all start Jest the same way. The ESM guide gives two forms, and the node form below needs no environment variable, which also spares Windows users the cross-env package the guide suggests for NODE_OPTIONS.

{
  "type": "module",
  "scripts": {
    "test": "node --experimental-vm-modules node_modules/jest/bin/jest.js"
  }
}

The config file needs the same switch. Under "type": "module", Node treats jest.config.js as an ES module, so a CommonJS config fails before Jest reads a single option; loading one in Node 25.5.0 printed this (path shortened, lines wrapped):

ReferenceError: module is not defined in ES module scope
This file is being treated as an ES module because it has
a '.js' file extension and '<project>/package.json'
contains "type": "module". To treat it as a CommonJS
script, rename it to use the '.cjs' file extension.

Write the config with export default instead. Jest's changelog lists defineConfig as new in Jest 30.3.0, the jest package exports it to ES modules, and a JavaScript file also skips the ts-node loader that Jest's configuration docs say a jest.config.ts needs by default.

import { defineConfig } from 'jest';

export default defineConfig({
  testEnvironment: 'node',
  extensionsToTreatAsEsm: ['.ts'],
});

• extensionsToTreatAsEsm - Jest already runs .mjs files, and .js files under a "type": "module" package.json, as ES modules; .ts files run as ESM only when their extension is listed here.
• supportsStaticESM - Jest's code transformation docs say a transformer is told it may emit ESM only when the file's extension is in extensionsToTreatAsEsm and Node runs with the flag, and every transform in Step 2 reads that value.
• The jest object - ES modules get no injected jest global, so import it from @jest/globals or use import.meta.jest, as the ESM guide shows.
• Global types - TypeScript 6.0 changed the types default to an empty list and TypeScript 7.0 kept it, per Microsoft's announcement, so describe and expect from @types/jest stop resolving until you add jest to types. Importing them from @jest/globals avoids the setting.

For code that Node runs directly, TypeScript's guide sets "module": "nodenext" and recommends verbatimModuleSyntax. The isolatedModules line is there for ts-jest, whose ESM guide accepts nodenext only with it, though it also stops ts-jest from type-checking, as Step 2 explains:

{
  "compilerOptions": {
    "module": "nodenext",
    "strict": true,
    "isolatedModules": true,
    "verbatimModuleSyntax": true
  }
}

Step 2: Pick a TypeScript Transform That Emits ESM

Jest's default transform runs babel-jest on every .js, .jsx, .ts and .tsx file, and the ESM guide leaves you a choice: switch transforms off with an empty transform, or use one that emits ESM instead of CommonJS. The table compares the TypeScript routes as their docs and published packages stood on November 11, 2026.

export default {
  testEnvironment: 'node',
  extensionsToTreatAsEsm: ['.ts', '.tsx', '.mts'],
  transform: {
    '^.+\\.m?tsx?$': ['ts-jest', { useESM: true }],
  },
};

// babel.config.cjs
module.exports = {
  presets: [
    ['@babel/preset-env', { targets: { node: 'current' } }],
    '@babel/preset-typescript',
  ],
};

// jest.config.js (babel-jest is the default transform)
export default {
  testEnvironment: 'node',
  extensionsToTreatAsEsm: ['.ts'],
};

export default {
  testEnvironment: 'node',
  extensionsToTreatAsEsm: ['.ts', '.tsx'],
  transform: {
    '^.+\\.(t|j)sx?$': '@swc/jest',
  },
};

export default {
  testEnvironment: 'node',
  extensionsToTreatAsEsm: ['.ts'],
  transform: {},
};

// sum.ts
export function sum(a: number, b: number): number {
  return a + b;
}

// user.ts
import type { User } from './types.js';
export const name = (u: User): string => u.name;

// status.ts
export enum Status {
  Active,
  Disabled,
}

--- sum.ts
export function sum(a        , b        )         {
  return a + b;
}
--- user.ts

export const name = (u      )         => u.name;
--- status.ts
ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX:
TypeScript enum is not supported in strip-only mode

src/status.ts(1,13): error TS1294: This syntax is not
allowed when 'erasableSyntaxOnly' is enabled.
src/user.ts(1,10): error TS1484: 'User' is a type and must
be imported using a type-only import when
'verbatimModuleSyntax' is enabled.

Step 3: Map .js Imports Back to .ts Files

Under "module": "nodenext", TypeScript checks imports the way Node resolves them, so a relative import has to name the compiled .js file. tsc 5.9.3 rejected the extensionless form in a sample project and passed once the import read './sum.js' (lines wrapped):

src/total.ts(1,21): error TS2835: Relative import paths
need explicit file extensions in ECMAScript imports when
'--moduleResolution' is 'node16' or 'nodenext'. Did you
mean './sum.js'?

Jest resolves that specifier as written. The default resolver in jest-resolve 30.5.1 passes no extension alias to unrs-resolver, and the file on disk is sum.ts, so the import fails unless a moduleNameMapper entry rewrites it first. Jest's configuration docs define the mapper as regular expressions mapped to module names, with numbered backreferences and the first matching pattern winning.

moduleNameMapper: {
  '^(\\.{1,2}/.*)\\.js$': '$1',
},

The ^(\.{1,2}/.*) part limits the rewrite to relative paths. Applied to five specifiers the way jest-resolve applies it (match first, then substitute the capture group), the entry printed this in Node 25.5.0:

./sum.js                -> ./sum
../lib/db.js            -> ../lib/db
./fixtures/user.json    -> (no match, resolved as written)
lodash-es/debounce.js   -> (no match, resolved as written)
uuid                    -> (no match, resolved as written)

• The relative anchor - once a pattern matches, jest-resolve requires the mapped name to resolve and otherwise stops with a "Could not locate module ... mapped as" configuration error, so an unanchored .js pattern can break package subpath imports.
• Regex checks - a JavaScript regex tester shows what a mapper key matches before Jest sees it.
• Bundler-style imports - with "moduleResolution": "bundler", relative imports carry no extension, and Jest finds the .ts file through moduleFileExtensions, whose default list includes ts.

Step 4: Mock ES Modules With jest.unstable_mockModule

Static imports are evaluated before any jest.mock() call runs, so the hoisting babel-jest performs for CommonJS cannot replace them. Jest's ESM guide documents jest.unstable_mockModule() instead: register the mock, then load the module under test with a dynamic await import().

import { jest, test, expect } from '@jest/globals';

jest.unstable_mockModule('./db.js', () => ({
  getUser: jest.fn(async (id: number) => ({ id, name: 'Ada' })),
}));

const { getUser } = await import('./db.js');
const { greet } = await import('./greet.js');

test('greets the user that db.js returns', async () => {
  await expect(greet(1)).resolves.toBe('Hello, Ada');
  expect(getUser).toHaveBeenCalledWith(1);
});

• Factory - the factory function is required, and it can be synchronous or async.
• jest.unstable_unmockModule() - restores the real module for imports that come after it.
• Automocks on Node 24.9+ - Jest 30.5 applies automocks and __mocks__ files to ES module graphs that evaluate synchronously; graphs with top-level await, or async-only resolvers and transformers, still need unstable_mockModule.
• CommonJS dependencies - jest.mock still works for CommonJS modules that the test loads through createRequire(import.meta.url).

ts-jest and TypeScript 7: Keep the TypeScript 6 API for Jest

The usual install command does not give you TypeScript 7. A dry run with npm 11.8.0 on November 11, 2026, resolved typescript to 6.0.3, because ts-jest 29.4.15 declares a peer range of >=4.3 <7, and the same command with typescript@7 stopped with ERESOLVE (output trimmed):

$ npm install --dry-run --save-dev \
    jest ts-jest typescript @types/jest
add babel-jest 30.5.2
add typescript 6.0.3
add ts-jest 29.4.15
add jest 30.5.2
add @types/jest 30.0.0

$ npm install --dry-run --save-dev \
    jest ts-jest typescript@7 @types/jest
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error Found: typescript@7.0.2
npm error Could not resolve dependency:
npm error peer typescript@">=4.3 <7" from ts-jest@29.4.15

The range is deliberate: Microsoft's TypeScript 7.0 announcement says the release "does not ship with an API" and expects a new, different one in TypeScript 7.1, and ts-jest's TypeScript 7 guide explains that ts-jest needs that JavaScript compiler API for transforms, diagnostics, source maps, hoisting and custom AST transformers.

ts-jest 29.4.12 added support for TypeScript 7 projects through npm aliases. TypeScript 7 installs as @typescript/native, so npx tsc runs the native compiler, and the @typescript/typescript6 compatibility package installs under the typescript name, which is the package ts-jest loads.

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

• No overrides - the guide says not to bypass ERESOLVE with --legacy-peer-deps, and not to point ts-jest's compiler option at @typescript/native.
• tsc as the type check - Jest transforms run at TypeScript 6 speed and report TypeScript 6 diagnostics, so the guide makes npx tsc --noEmit the authoritative project check in development and CI.
• tsc6 - the compatibility package also ships a tsc6 binary for comparing results between the two compilers.
• TypeScript 6.0 defaults - TypeScript 7.0 keeps them, including strict on, module set to esnext and an empty types list, and it rejects moduleResolution node10 and baseUrl outright, per Microsoft's announcement.
• The other routes - babel-jest, @swc/jest and Node type stripping do not use the TypeScript compiler API, so TypeScript 7 only changes the tsc step for them.

Run the ESM Suite in CI and on HyperExecute

Because the flag lives in the test script, any runner that calls npm test starts Jest in ESM mode, and the Node version is the only other setting to pin. Match it to your route: type stripping needs Node.js ^22.13.0 or >=23.2.0, Jest's require() of ES modules needs 24.9 or later, and Babel 8 needs ^22.18.0 or >=24.11.0.

TestMu AI's Jest on HyperExecute guide runs a Jest suite from hyperexecute.yaml with Auto-Split: a discovery command lists the test files, and each VM in the concurrency pool runs the npm test command from testRunnerCommand on its share of them. The runtime key installs the Node.js version you name, and the supported languages and packages list shows Node.js 12 through 20 on Linux, Windows and macOS, so a suite headed there fits ts-jest, @swc/jest or Babel 7.

version: 0.1
runson: linux
autosplit: true
concurrency: 2

runtime:
  - language: node
    version: "20"

pre:
  - npm install

cacheKey: '{{ checksum "package.json" }}'
cacheDirectories:
  - node_modules

testDiscovery:
  type: raw
  mode: remote
  command: grep -lr 'describe' src/*.test.ts

testRunnerCommand: npm test -- $test

Note: Run the same npm test script on HyperExecute, the test orchestration cloud from TestMu AI, which splits the discovered Jest files across parallel VMs with Auto-Split and returns the logs and reports for the whole job.

Conclusion

Start with one test file: add the flag to the test script, export the Jest config as an ES module, list .ts in extensionsToTreatAsEsm, and pick the transform that your Node version and type-checking needs allow. Keep tsc --noEmit beside Jest whichever route you choose, since only ts-jest can type-check during the run, and on TypeScript 7 its diagnostics come from the TypeScript 6 API.

When the suite passes locally, the HyperExecute YAML reference covers the runtime, caching and discovery keys used above. If you are new to Jest itself, the Jest tutorial starts from the first test. For a suite that also tests React components, the React Testing Library vs Enzyme comparison covers which library to use and how to move an Enzyme suite across.

Running JavaScript test suites in CI? HyperExecute by TestMu AI runs them from one YAML file and splits test files across parallel cloud VMs.

To run your first test, start free, or

book a demo

for a full walkthrough of the product.