Jest 27: ESM transform options are confused and conflicted to each other

🐛 Bug Report

ESM transform options which are passed to transformer appear in 2 places:

• From root of TransformOptions interface

• From transformerConfig property of TransformOptions interface

When I define ESM options in jest.config.js (in this case via preset), the values of these 2 above ways are not the same which creates confusion

My transform config:

module.exports = {
    '^.+\\.tsx?$': [
        'ts-jest',
        {
          supportsDynamicImport: true,
          supportsExportNamespaceFrom: true,
          supportsStaticESM: true,
          supportsTopLevelAwait: true,
        },
   ]
}

To Reproduce

Steps to reproduce the behavior:

• Check out https://github.com/ahnpnl/ts-jest-babel-example/tree/transform-options

• Install deps with yarn and run yarn test

• Observe in the console the 2 loggings

$ jest --no-cache
transformOptions.supportsTopLevelAwait false
transformOptions.transformerConfig.supportsTopLevelAwait true

Expected behavior

There should be a single place for those ESM options. If this is not possible, at least their values should be identical.

Link to repl or repo (highly encouraged)

https://github.com/ahnpnl/ts-jest-babel-example/tree/transform-options

envinfo

System:
    OS: macOS 11.0.1
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
  Binaries:
    Node: 14.15.1 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.0.14 - /usr/local/bin/npm
  npmPackages:
    jest: ^27.0.0-next.2 => 27.0.0-next.2 

cc @SimenB

[ahnpnl]

Thanks, all my doubts are solved 👍

[SimenB]

So I only need to use transformerConfig and ignore the other runtime flags ? Oh I think maybe both runtime and user configuration are better.

What you do with transformerConfig is up to you, but they will almost always not match the runtime so if you make decisions based on them you’ll either get a syntax error if there is ESM stuff, or runtime error if the code expects CJS stuff. Those flags are not configuration for the entire test run, they are runtime flags for the particular file we’re currently looking at transforming. I don’t think you should look at transformerConfig at all for determining ESM as the user cannot really know ahead of time - Jest uses different signals.

What you can do is add an option called useEsm or something, and if that is true while supportsStaticESM is false you can throw an error saying the user has misconfigured something.

---

In general, there is no single config option a user can use to “enable” ESM mode - the user has to follow the steps from https://jestjs.io/docs/en/next/ecmascript-modules

E.g. for .js files the closest packages.json#type must be modules, OR use .mjs file extension OR add their extension to extensionsToTreatAsEsm. In addition they’ll need to provide the runtime flag. Based on all of these things, Jest will then tell the transformer what syntax they can use.

In particular, if supportsStaticESM: true, CJS will not work, meaning no require, __filename, __dirname etc