ERR_REQUIRE_ESM when requiring .eslintrc.js

[indutny]

Tell us about your environment

macOS, node v12.11.0

• ESLint Version: 6.4.0
• Node Version: 12.11.0
• npm Version: 6.11.3

What parser (default, Babel-ESLint, etc.) are you using? default

Please show your full configuration:

Configuration

module.exports = {
    "env": {
        "browser": true,
        "es6": true
    },
    "extends": "eslint:recommended",
    "globals": {
        "Atomics": "readonly",
        "SharedArrayBuffer": "readonly"
    },
    "parserOptions": {
        "ecmaVersion": 2018,
        "sourceType": "module"
    },
    "rules": {
    }
};

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

I've set "type": "module" in the package.json of my project and run eslint

What did you expect to happen?

No internal errors in eslint

What actually happened? Please include the actual, raw output from ESLint.

> eslint lib/**/*.js test/**/*.js

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/findutnyy/Code/indutny/peerlinks/.eslintrc.js
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:958:13)
    at Module.load (internal/modules/cjs/loader.js:798:32)
    at Function.Module._load (internal/modules/cjs/loader.js:711:12)
    at Module.require (internal/modules/cjs/loader.js:838:19)
    at require (/Users/findutnyy/Code/indutny/peerlinks/node_modules/v8-compile-cache/v8-compile-cache.js:161:20)
    at module.exports (/Users/findutnyy/Code/indutny/peerlinks/node_modules/import-fresh/index.js:28:9)
    at loadJSConfigFile (/Users/findutnyy/Code/indutny/peerlinks/node_modules/eslint/lib/cli-engine/config-array-factory.js:189:16)
    at loadConfigFile (/Users/findutnyy/Code/indutny/peerlinks/node_modules/eslint/lib/cli-engine/config-array-factory.js:251:20)
    at ConfigArrayFactory._loadConfigDataInDirectory (/Users/findutnyy/Code/indutny/peerlinks/node_modules/eslint/lib/cli-engine/config-array-factory.js:436:34)
    at ConfigArrayFactory.loadInDirectory (/Users/findutnyy/Code/indutny/peerlinks/node_modules/eslint/lib/cli-engine/config-array-factory.js:401:18)

Are you willing to submit a pull request to fix this bug?

Maybe... although, it would require time to investigate this and learn the codebase first.

[bmeck]

This is from the change that disallows .js in packages declaring type: "module" to load via require(), nodejs/node#29492 . Tooling is advised to detect type: "module" and take the appropriate action to import any .js within.

[guybedford]

The ideal theoretical fix would be for your eslint file to be loaded as an ES module itself since the package boundary is supposed to have all .js files as ES modules by adding the type. Alternatively support could be added for eslint.cjs which is permitted inside of ESM package boundaries.

That is,

1. Use import() first if available to load configs, OR
2. Support eslint.cjs

[indutny]

Irrelevant now: Could the eslint config be put into package.json (Figured it out)

[kaicataldo]

Thanks for bringing this to the team's attention. We're tracking nodejs/modules#388 and would love to work with the wider tooling community to figure out how we as a community want to handle this, since it's going to affect so many projects. It would be great to standardize on something to lower the barrier for entry for using all these tools.

[mysticatea]

I have a question.

Is there a way that loads ES module files synchronously? Do we have to remove sync API (e.g. engine.executeOnFiles(...)) in order to support modules in config files?

[GeoffreyBooth]

I second @guybedford’s suggestions for how to make eslint compatible with "type": "module". A workaround that users can do today is to run eslint from a higher scope than the folder with the package.json that contains "type": "module". For example, if your project is in /app:

/app/.eslintrc.js
/app/package.json      # Main package.json for app, with "name", "main", "dependencies", etc.
/app/src/package.json  # Just { "type": "module" }
/app/src/...           # Rest of app in here

Since /app/package.json either wouldn’t have a "type" field or would have "type": "commonjs", .eslintrc.js would be loaded fine as CommonJS. And since /app/src/package.json would have "type": "module", all the .js files under /app/src/ would be loaded as ESM.

Presumably many projects using ES module syntax today already have their code in a subfolder like src, so simply adding a src/package.json that contains "type": "module" is all such users need to do. This additional package.json file doesn’t need any other keys—no "name", "main", "dependencies" or anything else.

Obviously it’s more ideal to have only one package.json rather than two, but this workaround should work for any tool with this same issue, until all such tools are updated to support .toolnamerc.cjs or using import() to load .toolnamerc.js inside a "type": "module" scope.

[jkrems]

Is there a way that loads ES module files synchronously?

Generally speaking - no. So using import may be tricky. What may work is:

1. Support .cjs so packages with { type: 'module' } can still use CJS for config files.
2. If require fails with ERR_REQUIRE_ESM, potentially use import or fail if it needs to stay sync. Alternatively, use require with sync config loading and import with async config loading if that part can be split out.

[Haroenv]

Note that simply changing the eslintrc.js won't work if you have any node plugins / configs written as eslintrc.js this error still happens, and you can stay on node v12.10.0 until a solution has been found for this.

[platinumazure]

Not speaking for the team here, this is just my own 2 cents.

When considering supported file types, module types, runtimes, etc., I think ESLint needs to consider those at two different levels:

• Code being linted/processed
• Configuration

ESLint has a philosophy of trying not to favor one runtime over others. I understand that philosophy as applying to "Code being linted/processed". We have features like env and shareable config to make files from certain environments easier to lint, but ESLint is fundamentally agnostic of the runtime environment as much as possible.

On the other hand, ESLint itself runs on Node.js. That is a specific decision we made-- we don't run(*) on browsers, RhinoJS, or other runtimes. We are a Node package.

So, for an issue like this that is about the execution of ESLint from Node, I think we need to follow Node.js's lead as much as we reasonably can and try to support different Node module styles, within reason. (This is not the same as saying we need to make ESLint async so it can be imported as an ES module itself.)

So based on that, if .cjs is official/not experimental (or will be very soon), I think we need to support it by allowing .eslintrc.cjs (and have it work the same as our current .js config implementation).

---

(*) Okay, we have webpack/browserify which creates a browser implementation, but that is not officially supported.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[platinumazure]

Latest discussion is happening here: eslint/rfcs#43

[avner-hoffmann]

What about backporting this to a latest stable release of eslint?
node version 16.13 won't work with eslint 6.8.0 because of that
Is this planned to be fixed on the latest release or only on eslint version 7 ?