Jest 30 config loading ambiguity with concurrent .cjs and .mjs files

Configuration Resolution Priority

In Jest 30, when both jest.config.cjs and jest.config.mjs exist in the root directory, Jest follows a deterministic internal priority list to select the configuration file. While the "type": "module" setting in package.json dictates how .js files are interpreted, .cjs and .mjs extensions are explicit signals to the Node.js loader and Jest.

Jest prioritizes jest.config.mjs over jest.config.cjs when ESM is enabled. This alignment ensures that projects opting into ES modules use the modern module system for their configuration by default.

Likely Behavior vs. Confirmed Facts

Confirmed Facts

• Explicit Overrides: Using the --config CLI flag bypasses all automatic discovery and forces Jest to use the specified file.
• Extension Explicitly: .mjs is always treated as an ES module, and .cjs is always treated as CommonJS, regardless of the package.json type field.
• Node Requirement: Node.js ≥14.18 is required for the underlying ESM loader support that Jest leverages.

Likely Explanation

The perceived non-determinism in some environments often stems from filesystem differences or cached configurations rather than a random selection process. However, maintaining both files is considered an anti-pattern because it creates ambiguity for developers and CI tools, even if the loader's priority list is technically fixed.

Steps to Ensure Determinism

1. Remove Ambiguity: Delete one of the two files. If you are using "type": "module", retain jest.config.mjs.
2. Explicit CLI Flag: If you must keep both for legacy support, specify the config in your package.json scripts:

   "test": "jest --config jest.config.mjs"

3. Verification: Run the following command to verify which file is currently active:

   npx jest --showConfig

   Check the output for specific settings (like displayName) that you have uniquely defined in one of the two files.

Missing Diagnostic: To provide a more precise answer regarding your specific environment, please clarify if you are running Jest via a wrapper (like ts-jest or babel-jest) or using the native node --experimental-vm-modules flag.