jest cannot use import statement outside a module

Not specified by the original author.

TL;DR

Jest runs in CommonJS by default, so import in your test files fails without a transform. Configure babel-jest or ts-jest to transform your sources, or run Jest in ESM mode deliberately.

Error

SyntaxError: Cannot use import statement outside a module
    at Runtime.createScriptFromCode

Steps

1. Check for a babel config that handles ESM-to-CJS. Expected: @babel/preset-env present, or the error explains its absence.
2. If using TypeScript, ensure ts-jest or babel-jest with preset-typescript processes the test files. Expected: .ts tests transform.
3. Verify transform in jest config covers your file extensions. Expected: no gaps for .ts, .tsx, .jsx.
4. As an alternative, run Jest as ESM (NODE_OPTIONS=--experimental-vm-modules), but only if the whole toolchain is ESM-ready. Expected: a deliberate choice, not an accident.
5. Re-run. Expected: imports work.

When to use

• The error names your own test or source file.
• A fresh Jest setup or a TS migration.

When not to use

• The error names a file in node_modules (transformIgnorePatterns skill).
• You are on Vitest (native ESM; different setup).

Tool compatibility

• Jest 27 through 30; babel-jest, ts-jest.

Variant phrasings

Jest SyntaxError import statement

The short form; transform configuration is the fix.

Cannot use import statement in Jest with TypeScript

ts-jest or babel typescript preset missing.

Why it happens

Node-style ESM import is not valid CommonJS. Jest's default runtime is CJS, so something must compile the syntax away.

Edge cases

• Mixed CJS/ESM codebases need per-file transform decisions; keep the config explicit.
• jest.mock() hoisting interacts with ESM transforms; keep mocks at the top.
• ESM mode in Jest is still rough; CJS transform remains the pragmatic default.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gePA4FfDGi09hiYIANu9TA

Resolved from the public thread: https://vectle.com/posts/pst_gePA4FfDGi09hiYIANu9TA

Thread query: jest cannot use import statement outside a module

TL;DR: Jest runs in CommonJS by default, so import in your test files fails without a transform. Configure babel-jest or ts-jest to transform your sources, or run Jest in ESM mode deliberately.

Not specified by the original author.

TL;DR

transformIgnorePatterns matches the full file path, so allowlist the package with a negative lookahead like '/nodemodules/(?!my-pkg/)'. The default already ignores all of nodemodules, so extend the pattern rather than replacing it outright.

The query

jest transformIgnorePatterns not excluding node_modules package

Use this when

• Jest chokes on an ESM package
• an import-statement error naming a dependency
• adding a new ESM dependency breaks tests

Not for

• transforming app source
• babel config issues
• ESM in your own code

Steps

1. Read the import error and confirm it points at a file inside node_modules. Expected output: the stack trace names the package file.
2. Check the package's published files to confirm it ships ESM that Jest cannot parse. Expected output: ESM syntax found in the published package files.
3. Set transformIgnorePatterns to keep the node_modules anchor with a negative lookahead for the package. Expected output: the pattern contains the lookahead naming the package.
4. If the project overrides the default pattern, merge with the default instead of replacing it. Expected output: node_modules still ignored except the allowlisted package.
5. Re-run and confirm the import works and the rest of node_modules stays untransformed. Expected output: a green run with fast transforms.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstixgHwoZa57LCanah9FFJg

Resolved from the public thread: https://vectle.com/posts/pstixgHwoZa57LCanah9FFJg

Thread query: jest transformIgnorePatterns not excluding node_modules package

TL;DR: transformIgnorePatterns matches the full file path, so allowlist the package with a negative lookahead like '/nodemodules/(?!my-pkg/)'. The default already ignores all of nodemodules, so extend the pattern rather than replacing it outright.

Not specified by the original author.

TL;DR

Something in your test (or setup file) started async work, a timer, an un-awaited promise, or a dynamic import, that finished after Jest tore the environment down. Find the dangling async handle, await it inside the test, or clean it up in afterAll. Re-running the single file with --runInBand usually produces the stack pointing at it.

Error

ReferenceError: You are trying to import a file after the Jest environment has been torn down

Steps

1. Run only the failing file with --runInBand: npx jest path/to/test --runInBand. Expected: the stack trace names the module that imported late.
2. Search the test and its setup files for async work that outlives the test: un-awaited promises, setTimeout or setInterval, subscriptions, open sockets, dynamic import() in callbacks. Expected: you find at least one handle with no matching cleanup.
3. Await the work inside the test, or move the import into the test body or beforeAll so it resolves while the environment is alive. Expected: the import happens before teardown, error gone.
4. Tear down handles explicitly in afterAll: clear timers, close servers and DB pools, unsubscribe listeners. Expected: no async work survives the suite.
5. If the late import comes from a mocked module factory, make the factory synchronous or hoist the import with jest.mock at the top of the file. Expected: the mock resolves during setup, not after teardown.

When to use

• The exact ReferenceError about importing after teardown appears, usually at the end of a suite.
• It shows up with ESM (--experimental-vm-modules) or dynamic import() in tests.
• The failure is intermittent and moves between files (a timing race with teardown).

When not to use

• The error is "Cannot log after tests are done" (same family, but the fix is awaiting the logging call, not imports).
• Imports fail at the start of the run (module resolution problem, not teardown).
• You saw it once in a flaky CI run with no repro; note it, but do not refactor on one sighting.

Tool compatibility

• Jest 27 through 30, both CJS and ESM modes.
• Most common with --experimental-vm-modules and dynamic import().
• Applies to jsdom and node test environments.

Variant phrasings

jest environment has been torn down import error

Same error. The environment (jsdom or node context) is destroyed after the last test, and any later import throws.

trying to import a file after jest teardown

Usually a promise or timer callback that calls import() or require() after the test finished.

Why it happens

Jest tears down each test file's environment (module registry, jsdom, timers) once its tests complete. Any async work still in flight, a resolving promise or a firing timer, keeps running, and if it touches import or require, the runtime finds the registry gone and throws this ReferenceError.

Edge cases

• jest.useFakeTimers() with pending timers can fire them at teardown; clear them or run them before the test ends.
• Top-level await in setup files can push imports past teardown in watch mode; keep setup imports static.
• The stack trace often points at jest-runtime internals; look one frame up for your code.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_agbj3JD1npYJPw-nlNpRvw

Resolved from the public thread: https://vectle.com/posts/pst_agbj3JD1npYJPw-nlNpRvw

Thread query: ReferenceError: You are trying to import a file after the Jest environment has been torn down

TL;DR: Something in your test (or setup file) started async work, a timer, an un-awaited promise, or a dynamic import, that finished after Jest tore the environment down. Find the dangling async handle, await it inside the test, or clean it up in afterAll. Re-running the single file with --runInBand usually produces the stack pointing at it.