Error [ERR_REQUIRE_ESM]: Must use import to load ES Module

[bcoe]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions: latest

Steps to reproduce

Install in Node 10 environment (I haven't tested on other node versions). Receive the following error:

Link to code example: https://github.com/googleapis/release-please/pull/870/checks?check_run_id=2390814891

Expected behavior

Library compiles.

I believe the goal is perhaps a dual-mode module (that would work for ESM and CJS?). This might just take some fiddling with extensions and export maps.

Here's what we landed on for yargs:

https://github.com/yargs/yargs/blob/master/package.json#L5

It's ugly but works on most Node versions.

Actual behavior

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/runner/work/release-please/release-please/node_modules/unist-util-visit/index.js
require() of ES modules is not supported.
require() of /home/runner/work/release-please/release-please/node_modules/unist-util-visit/index.js from /home/runner/work/release-please/release-please/build/src/util/to-conventional-changelog-format.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 index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /home/runner/work/release-please/release-please/node_modules/unist-util-visit/package.json.

[ChristianMurphy]

The goal is to go full ESM unifiedjs/unified#121
The reasons are similar to https://blog.sindresorhus.com/get-ready-for-esm-aa53530b3f77, and there are some related discussions and workarounds for build tools at sindresorhus/meta#15

[wooorm]

Oooh, the first issue where Beep Boop our bot is kicking in!

---

Yeah. The plan is to go with full ESM. In 8 days ESM is supported properly in all maintained Node release lines. And ESM works really well! ✨

[wooorm]

I don’t see this happening. For now, it’s possible to stay a release behind for a bit ’till you’re ready. But I expect (and hope) more folks will switch, making ESM more normal, and making supporting Node 10 less normal.

[wereHamster]

I'm using unist-util-visit from my next.config.js, which must be a .js file (.mjs isn't picked up), and I can't mark then package with type:module (because next.js uses require() to load the config file).

It's unfortunate to drop support for cjs, especially because it's relatively easy to support for pure modules (that contain just functions / consts and no global state), using the package.json import maps…

[wooorm]

• see the linked posts for more on this discussion and Next
• my experience maintaining dual esm/cjs is that there are tons of problems
• feel free to use the previous version while you or your tools are not ready

[Fhasghrge]

you can use version 2.0.1 instead

[johnrom]

FYI I came across this issue and wherever the workaround it posted, I wasn't able to find it right away. This is how I'm handling it.

I'm building a library using rollup. The solution I came up with was to transpile these libraries into the CJS version for backwards compatibility, but not the ESM version. This will obviously only work for modules which don't have state. React and the DOM will be your enemy, so hopefully they don't ditch CJS anytime soon. I have a feeling this workaround is somewhere in the various further reading here. You would do the same thing if you were targeting CJS in your browser or whatever -- just transpile the ESM to CJS via rollup or webpack.

const esmExternal = (source: string) =>
  !source.startsWith('.') && !path.isAbsolute(source);

// we pack ESM-only packages for CJS users, just to be nice.
const esmOnlyPackages = [/unist/];

const cjsExternal = (source: string) =>
  esmExternal(source) &&
  !esmOnlyPackages.find((esmOnlyPackage) => esmOnlyPackage.test(source));

const sharedConfig = {
  input: 'whatever.ts',
  plugins: [ allThePlugins() ],
}

export default [
  {
    ...sharedConfig,
    external: esmExternal,
    output: [
      {
        file: pkg.module,
        format: 'es',
      },
    ],
  },
  {
    ...sharedConfig,
    external: cjsExternal,
    output: [
      {
        file: pkg.main,
        format: 'cjs',
      },
    ],
  },
];

[wooorm]

Rollup is a bundler made for ESM. I don’t see why workarounds are needed to support ESM?

[johnrom]

Rollup is a bundler made for ESM. I don’t see why workarounds are needed to support ESM?

Workaround isn't needed to support ESM, it's used to support CJS consumers of a library built with rollup (or any bundler) (assuming they still exist out there in the world). I ran into this issue with an older Gatsby version that is otherwise working for now, for example.

Without this workaround, the cjs bundle will attempt to require the esm module upstream and receive this error.

[ApplyBoardDak]

unfortunately my organization requires CJS because of Jest so this is causing an issue even on version 5

[remcohaszing]

I recommend switching to Vitest. We stand by our choice to drop CJS support. Slowly but steadily more of the JavaScript ecosystem is adapting ESM.

[ChristianMurphy]

Sorry to hear that @ApplyBoardDak
The top recommendation: Migrate to vitest instead of jest, it is faster and fully supports ESM.
Otherwise try the workarounds described earlier in the thread.

I'm locking this thread, as it has been resolved, and isn't an issue in unist-util-visit but in an external tool.
Folks with questions on how to leverage ESM feel free to open a discussion forum post. https://github.com/orgs/syntax-tree/discussions/new?category=q-a