SyntaxError: Cannot use import statement outside a module, with TypeScript and ES Modules #9860

dandv · 2020-04-22T11:08:32Z

🐛 Bug Report

Filing a separate issue at @SimenB's suggestion.

After following the steps to get native ESM support, I'm running into the following error in a project that transpiles TypeScript files using @babel/preset-typescript:

/home/dandv/jets/lib.test.ts:1
import { foo } from './lib';
^^^^^^

SyntaxError: Cannot use import statement outside a module

  at Runtime._execModule (node_modules/jest-runtime/build/index.js:1074:58)

To Reproduce

git clone https://github.com/dandv/jest-typescript-es-modules.git
cd jest-typescript-es-modules
npm install
npm test

Expected behavior

Test passes.

Link to repl or repo (highly encouraged)

https://github.com/dandv/jest-typescript-es-modules

envinfo

System:
    OS: Linux 5.3 Ubuntu 18.04.4 LTS (Bionic Beaver)
    CPU: (8) x64 Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz
  Binaries:
    Node: 13.13.0 - /usr/bin/node
    npm: 6.14.4 - ~/.local/bin/npm
  npmPackages:
    jest: ^25.4.0 => 25.4.0

The text was updated successfully, but these errors were encountered:

SimenB · 2020-04-22T11:43:43Z

This is due to this check: https://github.com/facebook/jest/blob/6a0f070e0210eb11408a7c8ebb003ff73d62e420/packages/jest-resolve/src/shouldLoadAsEsm.ts#L51-L55

Not sure how to detect if it's an actual module or should use synthetic modules (like JSON). All current code only expects JS (we feed it to vm.Script), so might make sense to do the same here. If not, we'll need an option so the user can tell us.

@thymikee @jeysal thoughts?

askirmas · 2020-04-24T08:37:01Z

Take my transpile config
https://github.com/askirmas/askirmas.github.io/blob/8d1a0f2601c2683597edaa473f3b9ca9068abd72/jest.schema.json#L756-L773

dandv · 2020-04-25T06:53:58Z

@askirmas: doesn't that config transform imports, hence making moot the point of Jest natively supporting ES Modules?

SimenB · 2020-04-25T07:54:14Z

Yup. It's quite simple to fix, but I don't think we want to special case .ts, .tsx or .jsx for that matter. What about people using .coffee, .vue etc.?

Right now the logic is

.mjs is always ESM
.cjs is always CJS
.js is ESM if closest package.json has a type: 'module' field, otherwise CJS
all other extensions are CJS

What I'm thinking makes sense is to make that last one behave like js, i.e. infer from the type field. But it might be better to add an option that overrides this check and says "treat ts and tsx as ESM"?

dandv · 2020-04-25T10:53:30Z

Agree. I haven't seen TypeScript code yet that wasn't using import/export.

SimenB · 2020-04-25T10:56:56Z

Sure, but after transplantation it has to still use import, or require etc is undefined. Might need an option. esmExtensions?

jeysal · 2020-04-25T11:08:04Z

'transplantation', nice autocorrect 😅 but with Babel, TS is a completely different thing than CJS, if you use plugin-typescript but not plugin-transform-modules-commonjs, types get stripped but it remains ESM

SimenB · 2020-04-25T12:06:54Z

Hah, yeah. Which is why I think we might need an option instead of forcing or otherwise trying to infer it

GeoffreyBooth · 2020-04-27T15:55:39Z

What I'm thinking makes sense is to make that last one behave like js, i.e. infer from the type field.

Hi, I stumbled across this issue and thought I'd say hi. I'm the maintainer of CoffeeScript and I've been dealing with this same issue. In my case, there are plenty of legacy .coffee files out there that use require/CommonJS, including the CoffeeScript codebase itself. My plan is to treat .coffee as equivalent to .js, as in, “behave however a .js file would at this path”—so if it’s in a "type": "module" package scope, it's ESM. I think that's the safest approach; even if you think all TypeScript you'll ever encounter uses import/export, I wouldn't be surprised if there are some folks out there who have been mixing import and require statements occasionally, since presumably they currently work.

SimenB · 2020-04-27T16:11:22Z

Thanks for chiming in! I think that makes sense for us as well - it's what we already do for CJS - we require you to transform whatever you import to CJS before Jest will load it. And if you've opted into ESM for .js files I think it's a pretty safe assumption that you want the same behavior for your ts (or .coffee, .vue) files. Happy to hear people in the modules WG are thinking along the same lines 👍

ahnpnl · 2020-05-09T12:03:48Z

What I'm thinking makes sense is to make that last one behave like js, i.e. infer from the type field.

Hi, I stumbled across this issue and thought I'd say hi. I'm the maintainer of CoffeeScript and I've been dealing with this same issue. In my case, there are plenty of legacy .coffee files out there that use require/CommonJS, including the CoffeeScript codebase itself. My plan is to treat .coffee as equivalent to .js, as in, “behave however a .js file would at this path”—so if it’s in a "type": "module" package scope, it's ESM. I think that's the safest approach; even if you think all TypeScript you'll ever encounter uses import/export, I wouldn't be surprised if there are some folks out there who have been mixing import and require statements occasionally, since presumably they currently work.

cc @lmiller1990

Yup. It's quite simple to fix, but I don't think we want to special case .ts, .tsx or .jsx for that matter. What about people using .coffee, .vue etc.?

Right now the logic is

.mjs is always ESM

.cjs is always CJS

.js is ESM if closest package.json has a type: 'module' field, otherwise CJS

all other extensions are CJS

What I'm thinking makes sense is to make that last one behave like js, i.e. infer from the type field. But it might be better to add an option that overrides this check and says "treat ts and tsx as ESM"?

@SimenB Is it safe to use this approach for ts-jest as ts-jest only needs to transform ts/tsx to mjs/cjs depending on tsconfig target ?

Maybe only the case when transforming files from node_modules, it is necessary to check type: module in package.json

ghasemikasra39 · 2020-09-03T14:46:46Z

Getting the same issue

mnajjarian · 2020-09-23T08:22:00Z

I had the same problem. I've fixed that by including js files in ts-node:

"transform": { "^.+\\.(ts|tsx|js|jsx)?$": "ts-jest" }

ghasemikasra39 · 2020-09-23T08:27:03Z

I had the same problem. I've fixed that by including js files in ts-node:

"transform": { "^.+\\.(ts|tsx|js|jsx)?$": "ts-jest" }

Thanks Mahdi jan. Worked for me as well.

SimenB · 2020-10-23T18:09:27Z

My current thinking is that a transformer should return the format of the code it has transpiled.

Right now a transformer returns: https://github.com/facebook/jest/blob/1535af7659e0392b3f7c6124fa58d230907ee38d/packages/jest-types/src/Transform.ts#L9-L14

I'm thinking in addition it can return a moduleFormat?: 'ESM' | 'CJS' which we default to CJS. Thoughts?

A problem with this approach is that it might not be possible for a transformer to know - e.g. with the babel-jest transform shipped by default we can specify to Babel that we support ESM, but the user's Babel config can still transpile to CJS code. So I'm back to perhaps just a top-level configuration option allowing the user to say "all the files should be interpreted as ESM" (via some glob).

(https://en.wikipedia.org/wiki/Rubber_duck_debugging 😅)

SimenB · 2020-10-25T14:23:36Z

No, we won't be passing the result of one transformer into another. What would happen is that a user specifies "moduleFormat": "ESM" and somehow configures vue-jest to return ESM instead of CJS. Jest would then execute the ESM - no CJS transpilation at all

lmiller1990 · 2020-10-25T23:56:52Z

I see - I did not realize Jest could execute ESM (I have always been compiling to cjs). Is this via babel-jest?

This would be great, then we can target ESM and not bother with the cjs compilation step (vue-jest already supports both ESM and CJS).

SimenB · 2020-10-26T00:00:30Z

Yeah, I'm currently working (on and off) on adding native ESM support, see #9430. This issue is a small, but important part of that work 🙂

RowinVanAmsterdam · 2020-10-26T07:53:13Z

I like that suggestion! We already support passing config to transformers, like so
{
  "transform": {
    "\\.[jt]sx?$": ["babel-jest", { "rootMode": "upward" }]
  }
}
I guess we could have a third argument which is "config for jest"? Then stick moduleFormat in there.
{
  "transform": {
    "\\.[jt]sx?$": [
      "babel-jest",
      { "rootMode": "upward" },
      { "moduleFormat": "ESM" }
    ]
  }
}
We could also go for your suggestion of accepting an object - simple enough to normalize the user config into that as well.
{
  "transform": {
    "\\.[jt]sx?$": {
      "transformer": "babel-jest",
      "transformerOptions": { "rootMode": "upward" },
      "moduleFormat": "ESM"
    }
  }
}

I tried your suggestion, but unfortunately no luck for me yet. Project consists of .mjs, and commonJS. I added the transform in the package.json file and I receive the error on this line of code:
console.log(In ${window.location.href} starting script: ${import.meta.url})

I have to remove above line and add this part of code in the jest.config.file before my tests finally pass:

transform: {
    "^.+\\.jsx?$": "babel-jest",
    "^.+\\.mjs$": "babel-jest",
  }

As soon as I remove above transform and use your suggestion, it will throw me the same syntax error.

SimenB · 2020-10-26T15:23:56Z

Yeah, that's suggested syntax, it's not implemented yet. Will be included in Jest 27 which will come sometime before Christmas (hopefully earlier, but I don't wanna make any promises I'm not able to keep)

SimenB · 2020-11-14T13:57:37Z

OK, I've changed my mind (again) - I'm introducing a new top-level option called extensionsToTreatAsEsm - there you can pass e.g. .ts to have all TS files interpreted as ESM. Transformers will be called with supportsStaticESM: true which it can use to toggle import/export on and off.

Other behavior will remain as is - mjs is always ESM, cjs is always CJS and js will be interpreted based on type field in its closest package.json. This new option will only affect other extensions

ahnpnl · 2020-11-14T14:03:07Z

What is the advantage over the previous approach ? Is this top level option a part of global jest config or is it a part of transform config ?

SimenB · 2020-11-14T14:06:12Z

part of the Jest project config. This is passed to transformers, so you can use it if you want. I'd recommend relying on the passed supportsStaticESM tho as we might come via a require call

SimenB · 2020-11-14T15:08:34Z

@ahnpnl PR: #10823.

SimenB · 2020-12-05T17:49:38Z

I've published jest@next now, please give it a whirl! 🙂

oarthursilva · 2021-04-20T01:15:15Z

solved by adding "module": "commonjs" in tsconfig.json.

Basically, import modules are available on commonjs

github-actions · 2021-05-21T00:05:12Z

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

dandv added Bug Report Needs Repro Needs Triage labels Apr 22, 2020

dandv mentioned this issue Apr 22, 2020

Meta: Native support for ES Modules #9430

Open

21 tasks

SimenB added Confirmed ES Modules and removed Bug Report Needs Repro Needs Triage labels Apr 22, 2020

SimenB closed this as completed Apr 25, 2020

SimenB reopened this Apr 25, 2020

This was referenced Jun 3, 2020

import.meta not allowed kulshekhar/ts-jest#1174

Closed

Support ESM kulshekhar/ts-jest#1709

Closed

afc163 mentioned this issue Oct 2, 2020

Cannot test component wrapped with ConfigProvider ant-design/ant-design#26985

Closed

1 task

ahnpnl mentioned this issue Oct 23, 2020

Can't use top-level await kulshekhar/ts-jest#2057

Closed

SimenB added the 🚀 Feature Request label Oct 26, 2020

SimenB mentioned this issue Nov 3, 2020

chore: transformers must return objects, not strings #10773

Closed

SimenB mentioned this issue Nov 14, 2020

feat: support files other than js to be ESM #10823

Merged

SimenB closed this as completed in #10823 Dec 4, 2020

This comment has been minimized.

Sign in to view

SimenB mentioned this issue Dec 7, 2020

fix: move binary file declaration from runtime to repl #10925

Merged

This comment has been minimized.

Sign in to view

stellarator mentioned this issue Dec 8, 2020

jest.mock does not mock an ES module without Babel #10025

Open

This comment has been minimized.

Sign in to view

eunjae-lee mentioned this issue Apr 8, 2021

chore(test): use real search-insights to test the insights middleware algolia/instantsearch#4712

Merged

github-actions bot locked as resolved and limited conversation to collaborators May 21, 2021

SyntaxError: Cannot use import statement outside a module, with TypeScript and ES Modules #9860

SyntaxError: Cannot use import statement outside a module, with TypeScript and ES Modules #9860

Comments

dandv commented Apr 22, 2020

🐛 Bug Report

To Reproduce

Expected behavior

Link to repl or repo (highly encouraged)

envinfo

SimenB commented Apr 22, 2020

askirmas commented Apr 24, 2020

dandv commented Apr 25, 2020

SimenB commented Apr 25, 2020 • edited Loading

dandv commented Apr 25, 2020 via email

SimenB commented Apr 25, 2020

jeysal commented Apr 25, 2020

SimenB commented Apr 25, 2020 • edited Loading

GeoffreyBooth commented Apr 27, 2020

SimenB commented Apr 27, 2020

ahnpnl commented May 9, 2020 • edited Loading

ghasemikasra39 commented Sep 3, 2020

mnajjarian commented Sep 23, 2020

ghasemikasra39 commented Sep 23, 2020

SimenB commented Oct 23, 2020 • edited Loading

SimenB commented Oct 25, 2020

lmiller1990 commented Oct 25, 2020 • edited Loading

SimenB commented Oct 26, 2020

RowinVanAmsterdam commented Oct 26, 2020

SimenB commented Oct 26, 2020

SimenB commented Nov 14, 2020 • edited Loading

ahnpnl commented Nov 14, 2020

SimenB commented Nov 14, 2020 • edited Loading

SimenB commented Nov 14, 2020

SimenB commented Dec 5, 2020

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

oarthursilva commented Apr 20, 2021

github-actions bot commented May 21, 2021

SimenB commented Apr 25, 2020 •

edited

Loading

SimenB commented Apr 25, 2020 •

edited

Loading

ahnpnl commented May 9, 2020 •

edited

Loading

SimenB commented Oct 23, 2020 •

edited

Loading

lmiller1990 commented Oct 25, 2020 •

edited

Loading

SimenB commented Nov 14, 2020 •

edited

Loading

SimenB commented Nov 14, 2020 •

edited

Loading