Jest not transforming react-markdown when using the jsdom environment with TypeScript

[tubbo]

I'm making an Electron app that uses react-markdown. The app itself starts up and builds just fine, since I'm using Webpack to handle the compilation step. However, when trying to run tests that render react-markdown, I get the following error:

 FAIL  src/community/community.test.tsx
  ● Test suite failed to run

    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.

    By default "node_modules" folder is ignored by transformers.

    Here's what you can do:
     • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/configuration
    For information about custom transformations, see:
    https://jestjs.io/docs/code-transformation

    Details:

    /[...]/node_modules/react-markdown/index.js:5
    import { ReactMarkdown } from './lib/react-markdown.js';
    ^^^^^^

    SyntaxError: Cannot use import statement outside a module

    > 1 | import ReactMarkdown from 'react-markdown'
        | ^
      2 | import { FC } from 'react'
      3 | import { openMarkdownLinksInBrowser } from '~/cross-platform'
      4 | import View from '~/components/view'

      at Runtime.createScriptFromCode (node_modules/jest-runtime/build/index.js:1479:14)
      at Object.<anonymous> (src/components/markdown/markdown.tsx:1:1)

I've tried to configure my way out of this with Jest but I can't seem to get it to transpile the module with Babel...

module.exports = {
  preset: 'ts-jest',
  setupFilesAfterEnv: ['<rootDir>/src/test-utils/setup-tests.ts'],
  moduleNameMapper: {
    '\\.(css|less|scss|sass)$': 'identity-obj-proxy',
    '\\.(jpg|jpeg|png|gif|eot|otf|webp|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$':
      '<rootDir>/src/__mocks__/file-mock.ts',
    '\\.svg$': '<rootDir>/src/__mocks__/svgr-mock.tsx',
    '~/(.*)': '<rootDir>/src/$1',
  },
  slowTestThreshold: 30,
  coveragePathIgnorePatterns: [
    '/node_modules/',
    '<rootDir>/src/graph/operations.ts',
  ],
  timers: 'modern',
  testEnvironment: 'jsdom',
  globals: {
    'ts-jest': {
      babelConfig: {
        presets: [['@babel/preset-env', { targets: { esmodules: false } }]],
        plugins: [
          ['@babel/plugin-transform-react-jsx', { runtime: 'automatic' }],
        ],
      },
    },
  },
  transformIgnorePatterns: [],
  transform: {
    '\\.js$': 'babel-jest',
  },
}

Just to make sure I wasn't totally crazy, or there wasn't something else blocking me here in my tooling, I made a reproduction of my issue at https://github.com/tubbo/react-markdown-repro. If you yarn eject in that repo and change transformIgnorePatterns: [], the test will pass. But I don't think that will work for my (much larger) Electron repo, since it has so many dependencies. Also, trying to whitelist every last dependency that react-markdown uses is an absolute nightmare because the moment you try and import an ESM module, Node just uses ESM for the entire tree downward, so you end up yak-shaving the ignore pattern. I got to about 30 packages before I gave up, not worth anyone's time.

So what do we do about this? How does anyone actually run a test that happens to include this module? I'm totally happy mocking it out for now just to keep things moving...just wondering how everyone who uses this component in the real world got past this problem in their testing phase?

[wooorm]

How does anyone actually run a test that happens to include this module

Several test runners do support ESM.

---

Did you try these steps?

[tubbo]

I did, sorry for not mentioning that. The project I'm working on uses TypeScript, Electron Forge, and Webpack. When I tried converting over to ESModules syntax, I got this error:

✔ Checking your system
✔ Locating Application
Failed to load: /Users/tscott/Code/nerdst/forge.config.js

An unhandled rejection has occurred inside Forge:
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/tscott/Code/nerdst/forge.config.js
require() of ES modules is not supported.
require() of /Users/tscott/Code/nerdst/forge.config.js from /Users/tscott/Code/nerdst/node_modules/@electron-forge/core/dist/util/forge-config.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename forge.config.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/tscott/Code/nerdst/package.json.

    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1089:13)
    at Module.load (internal/modules/cjs/loader.js:937:32)
    at Function.Module._load (internal/modules/cjs/loader.js:778:12)
    at Module.require (internal/modules/cjs/loader.js:961:19)
    at require (internal/modules/cjs/helpers.js:92:18)
    at _default (/Users/tscott/Code/nerdst/node_modules/@electron-forge/core/src/util/forge-config.ts:123:21)
    at _default (/Users/tscott/Code/nerdst/node_modules/@electron-forge/core/src/api/start.ts:40:23)
    at /Users/tscott/Code/nerdst/node_modules/@electron-forge/cli/src/electron-forge-start.ts:58:19 {
  code: 'ERR_REQUIRE_ESM'

This seems to be because electron-forge itself is not ready for ESM just yet..

Since I'm running Webpack and using Babel (for the new React JSX transform), all the Remark modules are compiling properly in the real world. It's just Jest that's having the problem. So I'm hesitant to start reconfiguring my whole project in order to satisfy my tests..

My current workaround is to just mock out the <ReactMarkdown /> component and the remark plugins that I'm using. None of my tests are currently looking for content rendered from Markdown, thankfully, so that does cause my tests to pass.

Here's what I did:

diff --git a/jest.config.js b/jest.config.js
index 47b3650..c52d7b2 100644
--- a/jest.config.js
+++ b/jest.config.js
@@ -7,6 +7,8 @@ module.exports = {
       '<rootDir>/src/__mocks__/file-mock.ts',
     '\\.svg$': '<rootDir>/src/__mocks__/svgr-mock.tsx',
     '~/(.*)': '<rootDir>/src/$1',
+    'react-markdown': '<rootDir>/src/__mocks__/react-markdown.tsx',
+    'remark-*': '<rootDir>/src/__mocks__/remark-plugin.ts',
   },
   slowTestThreshold: 30,
   coveragePathIgnorePatterns: [
@@ -25,9 +27,4 @@ module.exports = {
       },
     },
   },
 }
diff --git a/src/__mocks__/react-markdown.tsx b/src/__mocks__/react-markdown.tsx
new file mode 100644
index 0000000..7fe3ce2
--- /dev/null
+++ b/src/__mocks__/react-markdown.tsx
@@ -0,0 +1,6 @@
+// eslint-disable
+// @ts-ignore
+export default function ({ children }) {
+  return <>{children}</>
+}
+// eslint-enable
diff --git a/src/__mocks__/remark-plugin.ts b/src/__mocks__/remark-plugin.ts
new file mode 100644
index 0000000..ea9b101
--- /dev/null
+++ b/src/__mocks__/remark-plugin.ts
@@ -0,0 +1 @@
+export default function () {}

So I guess the real blocker here is Electron Forge, but I'm also not really fond of Jest either at the moment. I just wish everyone could standardize on a way to compile JS, because if Jest could just use my Webpack to do all the transformation , I would not only be able to accurately predict when Webpack config changes break my app, but also I'd avoid problems like this.

Anyway, this doesn't have much to do with Remark. :)

[wooorm]

You will indeed find more problems with Electron. And indeed, Electron Forge, which I don’t know. It might be that there are issues around for that project already that might guide you towards a solution.

I just wish everyone could standardize on a way to compile JS [...]

Luckily we’re moving towards that with ESM — unfortunately not everything supports it though, as you’re noticing