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

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

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

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.

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 👍

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

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)

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 🙂

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

‘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

yeyy tests run now 😃

Only real drawback is that it’s a breaking change. Should be fine tho, let’s go for it. PR welcome, if not I’ll get to this in a few weeks 👍

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"
    }
  }
}

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?

This one is very simple indeed and easy to do.

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)

Top level configuration option is also fine by me. Currently, ts-jest has internal logic to detect whether users want to use babel-jest.

I think we can also have

{
     "\\.[jt]sx?$": {
           transformer: "babel-jest",
           moduleFormat: "ESM"
      }
}

??

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”?

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