Change Request: [new config system] Allow async configs

[mdjermanovic]

ESLint version

v8.33.0

What problem do you want to solve?

#16580 (comment)

If eslint.config.js must be a CJS module because the project is "type": "commonjs" (default; i.e., the project does not have "type": "module" in its package.json file), then it isn't possible to use ESM dependencies in eslint.config.js because the only way to load ESM from CJS is by using import(), but that returns a Promise.

What do you think is the correct solution?

Allow async function configs, as proposed in the RFC:

• https://github.com/eslint/rfcs/blob/main/designs/2019-config-simplification/README.md#function-configs
• https://github.com/eslint/rfcs/blob/main/designs/2019-config-simplification/README.md#can-a-config-be-an-async-function

so that ESM dependencies can be used like this:

// eslint.config.js
module.exports = async () => {

    const someDependency = await import("some-esm-dependency");

    return [
        // ... use `someDependency` here
    ];

};

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[nzakas]

You can already use -c eslint.config.mjs and it will work as expected. It seems like that solves the use case for a CommonJS-only project?

As I've mentioned elsewhere, I just don't think it's a good idea to make concessions for CommonJS at this point in JavaScript's lifecycle. It will be used less and less, as long as we already have a workaround, I don't feel like anything else is needed.

[sam3k]

Hi @mdjermanovic, based on @nzakas comment, it might make sense to close this issue since there are workarounds. I'll go ahead and close it; but please feel free to reopen if you think otherwise.

[nzakas]

@sam3k Please meet @mdjermanovic 😄 He's a member of the ESLint team, so we like to leave these open until the team comes to a resolution. You can notice this on issues by the "Member" tag that appears in the upper-right corner of each comment.

In general, when team members open issues, we can just skip them right to "Ready for Dev Team".

[sam3k]

@nzakas Ah! My bad. Noted. 😄

[nzakas]

@sam3k no problem at all -- I should have mentioned this to you. Feel free to update the triage docs as we discover little glitches in the system like this.

[mdjermanovic]

You can already use -c eslint.config.mjs and it will work as expected. It seems like that solves the use case for a CommonJS-only project?

It works on the command line, but requires additional setup in IDEs and therefore doesn't seem like a convenient workaround.

As I've mentioned elsewhere, I just don't think it's a good idea to make concessions for CommonJS at this point in JavaScript's lifecycle. It will be used less and less, as long as we already have a workaround, I don't feel like anything else is needed.

I think we should provide a way for the ESLint ecosystem to switch to ESM while not dropping support for CommonJS end users. If ESM plugins cannot conveniently be used in CJS projects, that will force plugins (and shareable configs) to stay on CJS or at least provide a CJS export, which means that they cannot use ESM-only dependencies.

[nzakas]

I think we should provide a way for the ESLint ecosystem to switch to ESM while not dropping support for CommonJS end users. If ESM plugins cannot conveniently be used in CJS projects, that will force plugins (and shareable configs) to stay on CJS or at least provide a CJS export, which means that they cannot use ESM-only dependencies.

I understand this line of thinking, I just disagree. Plugins can choose to also export CJS entrypoints if they want compatibility; current CommonJS users can stick with .eslintrc for probably the next year or two.

I just really don't like the complexity tradeoff to support a shrinking number of users. I also think that nudging more folks towards ESM is arguably a net positive for the ecosystem.

At the least, I think we should defer a decision here until we send out our survey and see what sort of data we get back about CJS vs. ESM.

[morganney]

At the least, I think we should defer a decision here until we send out our survey and see what sort of data we get back about CJS vs. ESM.

Why? You already know CJS will be a shrinking population of the user base. Why not stop all future development supporting CJS to some semver and start all future feature development on a different semver that only supports ESM?

[nzakas]

@morganney As you can tell from this thread, there is disagreement on this approach, and so gathering some data will help to make the decision easier.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[Rec0iL99]

Not stale. Discussion around the issue is going on.

[fasttime]

It is already possible to use asynchronous code (like dynamic imports) in a CommonJS config file by exporting a promise. For example, to amend the sample config in the original post, one could simply wrap the async function in an IIFE, i.e.

// eslint.config.js
module.exports = (async () => {

    const someDependency = await import("some-esm-dependency");

    return [
        // ... use `someDependency` here
    ];

})();

To tell the truth, I've already used this pattern before (repro). Now I realize that this usage was not intended.

[mdjermanovic]

It is already possible to use asynchronous code (like dynamic imports) in a CommonJS config file by exporting a promise. For example, to amend the sample config in the original post, one could simply wrap the async function in an IIFE, i.e.

// eslint.config.js
module.exports = (async () => {

    const someDependency = await import("some-esm-dependency");

    return [
        // ... use `someDependency` here
    ];

})();

To tell the truth, I've already used this pattern before (repro). Now I realize that this usage was not intended.

Interesting, this really works in the current version because loadFlatConfigFile() just returns that promise and it ends up being await-ed before used as a config object. I think this wouldn't work in versions before df77409.

I'm pretty sure this wasn't intended to work, but perhaps we could make it official by adding tests.

[fasttime]

Interesting, this really works in the current version because loadFlatConfigFile() just returns that promise and it ends up being await-ed before used as a config object. I think this wouldn't work in versions before df77409.

This seems to be already working in v8.23.0, hence before that commit.

I'm pretty sure this wasn't intended to work, but perhaps we could make it official by adding tests.

There is clearly a use case here, so it seems reasonable to add unit tests. I'd be also not opposed to documenting the current behavior, rather than keeping it as an Easter egg. We should wait to see what @nzakas thinks.

[nzakas]

Nice find @fasttime! Given that this has worked for the past eight months, I'm in favor of documenting it as expected functionality and adding tests to verify. 👍

[mdjermanovic]

Looks like we've agreed to officially allow eslint.config.js config files to export a Promise. That solves the problem of using ESM dependencies in CJS config files.

I can work on this.