Support ESM config (.eslintrc.mjs)

[jsejcksn]

Search terms used: is:issue is:open mjs OR esm OR "es module"

cf. #12593, which was auto-closed. All of the issues/RFCs mentioned as blockers in that issue are now closed/merged.

What is the status of ES module support for config files? In the form of

• .eslintrc.mjs or
• .eslintrc.js where the nearest package.json includes "type": "module"

[kaicataldo]

Now that we have an asynchronous API, I believe that supporting .mjs is unblocked from a technical standpoint. For the second bullet point, ESLint does already support .eslintrc.cjs files, so this should not be an issue (see here for more details).

[kaicataldo]

Would you like to create an RFC for adding support for .mjs?

[jsejcksn]

@kaicataldo Oh, wow—I thought this was already on the roadmap based on all of the discussion around it. I’ll take a look at the RFC process. Does it require having any knowledge of ESLint’s internal API (not user API)?

[kaicataldo]

The RFC template is a section for outlining what kind of changes would be required to implement it, which is really useful both for evaluating trade offs as well as for whoever ends up implementing the accepted RFC.

This is definitely something we want to do, but I do think it makes sense to go through this process to make sure we approach it thoughtfully.

[jsejcksn]

@kaicataldo I looked and I don't think I have enough knowledge about ESLint internals to provide implementation details. Is there an RFC for an RFC 😄?

[kaicataldo]

Ha! My personal take is that this is something we’re going to have to implement eventually anyway, if you’re willing to wait :)

In the meantime, it should be possible to use a .eslintrc.cjs configuration file.

[jsejcksn]

Sure—I just didn't see a place to track ESM configs specifically, so I created this issue.

[Rishabh-malhotraa]

@kaicataldo I would like to try to solve this issue :)

[kaicataldo]

@Rishabh-malhotraa Great! As mentioned above, the next step is create an RFC for this so that we can decide how this should be implemented.

[nzakas]

Given that we are moving forward with a different config system, I think any changes should be proposed for the new system rather than continuing to modify the current system.
eslint/rfcs#9

[jsejcksn]

Given that we are moving forward with a different config system

@nzakas I thought it was just an RFC at this point. Especially in consideration of the statement in your most recent message, isn’t it prudent to support ESM in the current system?

[nzakas]

The RFC was accepted several months ago and will be the new config system for ESLint. There were some outstanding questions that had to be answered so I kept iterating until we got most of them ironed out. It will be formally merged this week with development starting next week.

I don’t see a scenario where it makes sense to update the eslintrc config system to support ESM. The simple config system actually makes supporting ESM super easy, though I’m not sure I’d want to support the .mjs extension as I think that will be a relic in the next couple years. However, we could support ESM in simple config files relatively easily.

[ljharb]

@nzakas i'm not sure why it'd be a relic; it'll be supported by node for the foreseeable future, and is the best way to avoid ambiguity about what .js means (which is "not a module", unless you use the type field to subvert that).

[nzakas]

@ljharb I just don't foresee people using it much after the transition period from CJS to ESM. Right now, it's a stopgap for needing to support both in Node.js packages, but eventually (and probably sooner than we realize), no one is going to be writing CJS, so I'm not sure it's worth adding in support for a stopgap measure that eventually won't be used.

[ljharb]

imo that's entirely false :-) people are still writing ES5, and sloppy code, and Scripts, and I think CJS will be around for effectively ever. Obv we don't have to agree here, but the node modules group is expecting a minimum of 10 years before it'd even be remotely possible to consider deprecating any CJS features.

[nzakas]

Here's the nice thing about my approach: if I'm wrong, we can always add support for .mjs later. I'm just less inclined to add a feature that may or may not be needed because we already have nearly seven years of backwards compatibility cruft in ESLint that we really can't remove, so I don't want to add more unless we need it.

[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.

[nzakas]

As a final note here: ESM config will be part of the eslint/rfcs#9 implementation.

[KilianKilmister]

@kaicataldo

In the meantime, it should be possible to use a .eslintrc.cjs configuration file.

Well yes, but only sort of. I just tried to use a dynamit import( ) statement in my config, but eslint isn't able to use that.
I'm in the process of filing an issue about it with the details. issue filed