[Feature]: Support jest.config.mts config file extension

[floriangosse]

🚀 Feature Proposal

Jest should support jest.config.mts as a valid configuration file extension. When detected, Jest should always resolve and load this file as an ESM module regardless of the type field in the project's package.json.

This aligns with the behavior established by the Node.js ecosystem, where .mts / .mjs files are unconditionally treated as ES modules.

Motivation

Currently, Jest supports jest.config.ts, jest.config.js, jest.config.cjs, and jest.config.mjs but not the TypeScript ESM equivalent .mts. This creates a pain point in several scenarios:

• Mixed-module projects: In projects that use "type": "module" in package.json, authors may want their config file to explicitly signal its module format independently of the package-level setting. A .mts extension makes the intent unambiguous.
• TypeScript moduleResolution: "nodenext" / "node16": Under these resolution modes, TypeScript itself distinguishes between .mts (ESM) and .cts (CJS). Authors writing their config in TypeScript expect Jest to respect the same convention. See the TypeScript module format detection docs for details on how file extensions determine module format.
• Consistency with the ecosystem: Tools like Vite (vite.config.mts), esbuild, and tsx already recognize .mts files. Jest not supporting them forces workarounds (e.g., renaming to .mjs and losing type-checking, or adding boilerplate type flags).

Without this feature, users in ESM-first TypeScript projects are left with fragile configurations that depend on package.json type fields or extra tooling to transpile their config.

Example

A user would simply create a jest.config.mts file in their project root:

// jest.config.mts
import type { Config } from '@jest/types';

const config: Config.InitialOptions = {
  testEnvironment: 'node',
  extensionsToTreatAsEsm: ['.ts'],
  transform: {
    '^.+\\.tsx?$': ['ts-jest', { useESM: true }],
  },
};

export default config;

Jest would pick it up automatically (following the existing config resolution order), detect the .mts extension, and always load it via the ESM loader. So, no additional flags or package.json changes required.

The expected resolution priority could look like this:

jest.config.ts
jest.config.mts   ← NEW (always ESM)
jest.config.js
jest.config.mjs
jest.config.cjs
jest.config.json

Similarly, --init could gain an option to scaffold a .mts config when the user indicates an ESM + TypeScript setup.

Pitch

This feature belongs in Jest core because config file resolution is a core responsibility — it cannot be reasonably handled by a plugin or third-party transformer.

• Low surface area: The change is scoped to the config resolution and loading logic. The .mts extension maps directly to an already-supported code path (ESM loading); it simply needs to be recognized as a valid config file extension and routed accordingly.
• Node.js alignment: Node.js has established .mts as the canonical way to force ESM. Jest already respects .mjs for JavaScript configs — extending this to the TypeScript equivalent is a natural and expected next step.
• Reduces friction: As the ecosystem increasingly moves toward ESM-first TypeScript projects, not supporting .mts becomes a growing source of configuration issues and Stack Overflow questions. Supporting it out of the box removes an unnecessary barrier to adoption.