SyntaxError: Unexpected token 'export' in jest

[prachit07]

After updating to 2.8.0, we are facing the following issue in Jest unit testing

SyntaxError: Unexpected token 'export'. node_modules/@reduxjs/toolkit/dist/redux-toolkit.browser.mjs:1

Jest encountered an unexpected token

    Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.

    Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.

[ska-kialo]

You can use a moduleNameMapper in your jest config to point to the CJS file (node_modules/@reduxjs/toolkit/dist/cjs/index.js), see here for an example: https://stackoverflow.com/a/69230389

[joshkel]

I typically fix these problems by adding affected NPM modules to my Jest configuration's transformIgnorePatterns. Normally, Babel ignores anything in node_modules, but excluding @reduxjs/toolkit from the ignore pattern will let Babel transpile the ESM export. For example, to ignore most modules but let Babel transform Redux Toolkit and Apache ECharts:

    transformIgnorePatterns: [
    '[/\\\\]node_modules[/\\\\](?!' +
      [
        '@reduxjs/toolkit',
        'echarts',
      ].join('|') +
      ')',
  ],

[markerikson]

Jest should not be detecting and loading the browser build artifact (or to put it another way, we aren't trying to make Jest detect that file). Can you give an example of your Jest setup?

[prachit07]

moduleNameMapper solved the issue for me

[markerikson]

@prachit07 : it's still not expected that this release would have broken anything with Jest, even though we did change the package definitions. We don't want our users to have to manually override which build artifact gets used - it should Just Work Right.

Could you please provide an example of your Jest config, and ideally a minimal repro that shows this happening?

[joshkel]

@markerikson When using jest-environment-jsdom, Jest pretends to be a browser environment as much as it can - including using the browser export conditions for modules that test cases load. See the customExportConditions description at https://jestjs.io/docs/configuration#testenvironmentoptions-object.

(As I understand it, overriding moduleNameMapper works because it bypasses those customExportConditions.)

[aryaemami59]

@prachit07 can you share what your jest.config.js file looks like anyway? I want to make sure the latest changes we made are not going to cause additional problems, thanks.

[EskiMojo14]

Another potential "fix" would be replacing jest-environment-jsdom with jest-fixed-jsdom, a wrapper that removes the problematic export conditions and preserves Node globals - published by the MSW team as they were affected by the same issues. Generally I would say this is Jest's problem - you shouldn't be claiming to be a browser if you cannot run things that would run in a browser.

[markerikson]

Some more details after internal discussion:

• We added the browser condition to our packages to better support the JSPM tool / package manager (per issues like Please remove process.env.NODE_ENV in dist/immer.mjs immerjs/immer#1141 and UMD distributions from 2.0 onwards #4278 )
• However, it seems that per above, jest-environment-jsdom also looks at the browser field, and yet Jest doesn't deal well with the ESM export keyword

So we've got a tool expectations conflict. JSPM is presumably more correct here, but Jest and jest-environment-jsdom are much more widely used.

I want RTK to work out of the box in as many environments as possible, but it seems like we're in something of a no-win scenario here. I'd lean towards "jest-environment-jsdom is at fault here".

Given that, yeah, I'd say the "best" answer here is to either use Vitest, or switch from jest-environment-jsdom to jest-fixed-jsdom.

I'll leave this open for further discussion, but that's probably going to be the recommendation.

[joshkel]

I'd say the "best" answer here is to either use Vitest, or switch from jest-environment-jsdom to jest-fixed-jsdom.

For completeness' sake, there are a few options. In order of roughly increasing impact:

1. Modify transformIgnorePatterns to let Jest + Babel transpile Redux Toolkit's ESM code (for performance, Jest skips transpiling node_modules by default) while continuing to use the browser build of Redux Toolkit.
2. Override Jest's moduleNameMapper to instruct Jest to use the non-browser build of Redux Toolkit. (You could also use a custom resolver, but that seems like more work to accomplish the same result.)
3. Configure Jest's testEnvironmentOptions customExportConditions to change all packages to use non-browser versions.
4. Switch to jest-fixed-jsdom to change all packages to use non-browser versions and restore some Node.js globals.
5. Enable Jest's modules support and use Redux Toolkit's browser build as is.
6. Switch to Vitest.

In my case, I was already using option 1 to transpile several ESM modules, so adding Redux Toolkit was an easy tweak.

Option 5 seems best long term for Jest users but may raise other concerns about tooling support and stability.

Option 2 seems straightforward and is lower impact than changing to Vitest or jest-fixed-jsdom; that would be my recommendation for anyone not interested in trying option 5 or 6. There are enough ESM packages out there now that anyone who's still using Jest without enabling modules support is probably going to have to get used to dealing with issues like this, for better or worse.

I'm more sympathetic to jest-environment-jsdom's claiming to be a browser here - it wants to emulate a browser environment as much as it can, and that would seem to include using browser builds of packages. Of course, problems then arise when it can't fully do so, due to limitations of Node.js, jsdom, and/or Jest.

Just my two cents.

[meabed]

Thank you @joshkel - option 2, 4 is working well

For moduleNameMapper here is the snippet:

const { pathsToModuleNameMapper } = require('ts-jest');
const { compilerOptions } = require('./../tsconfig');
const createJestConfig = nextJest({
  dir: './'
});

const paths = compilerOptions.paths || {};
// the fix for reduxjs/toolkit
paths['@reduxjs/toolkit'] = ['node_modules/@reduxjs/toolkit/dist/cjs/redux-toolkit.production.min.cjs'];

const customJestConfig = {
  preset: 'ts-jest',
  testEnvironment: 'jsdom',
  moduleNameMapper: pathsToModuleNameMapper(paths, {
    prefix: '<rootDir>/../'
  }),
  transform: {
    '^.+\\.ts?$': ['ts-jest', { isolatedModules: true }]
  }
};

module.exports = createJestConfig(customJestConfig);