Enable eslint.config.mjs and eslint.config.cjs as options
nzakas opened this issue · comments
Based on the discussion around the DefinitelyTyped monorepo use case, we've decided to add support for eslint.config.mjs and eslint.config.cjs by default.
Background
Originally, we had decided to only support automatically looking for eslint.config.js files for flat config. Contrary to what folks have been saying online, this decision with not about forcing people to use ESM. Because we were rebuilding the config system from the ground up, we wanted to start with as minimal a feature set as possible to avoid over-engineering the solution. We believed that supporting just eslint.config.js would be sufficient for almost all cases because people would most likely want to use the same format (module vs. commonjs) as they were using for their source code. Additionally, CommonJS files can load ESM modules via import(), so it seemed like there wasn't a concern about which config files could access which packages.
We also provided the -c command line flag that would allow anyone to specify an alternate filename, including .mjs and .cjs files. We thought this would be enough to solve most use cases.
The complexity of the DT monorepo coupled with how difficult it is to configure the VS Code ESLint extension for alternate filenames convinced us that a more automatic solution was needed.
Implementation Details
ESLint will search for eslint.config.js, eslint.config.mjs, and eslint.config.cjs in that order and the first one found wins and the others will be ignored. Exactly which config file being used will be output using --debug, so you'll always be able to tell which one you're using. You won't get a warning if you have multiple config files because we stop searching once the first config file is found.
Timeline
We intend to complete this for the alpha release on December 29th, however, we need to wait until we've merged all of the other flat config changes first. Otherwise, there will be a mountain of merge conflicts to deal with.
I'd like to work on this.
Are we sure that this change is what DT actually needs? From the discussion, it seems that what would benefit them more is a way to describe the config statically (like a .json file), to avoid code injection when a PR that changes the config is merged automatically.
Looking at @jakebailey's reactions to this issue and the discussion, it appears that the feedback to this approach is positive, but I'll leave it up to him / DT to respond.
Outside of DT, there is also positive feedback to this change too 👍
I wasn't expecting you all to want to change your tune on configs needing to be executable; it'd be bringing back all of the same funky resolution stuff. So, I viewed just the option to use .mjs everywhere as "good enough" to solve things.
I will note that I have not had time to attempt to convert DT to flat config, so I have not tried out the "one single config at the top that parses the 2000 eslintrc.json files" idea. Theoretically that would "fix" things without requiring any change to eslint, but I suspect that it will not be performant.
I also think that the benefit of this change extends beyond DT by arguments similar to mine; a slight amount of complexity increase here will lead to a much lower amount of complexity elsewhere thanks to stuff like no longer needing to configure every editor to use a .mjs config file (and also, help make ESM eslint plugins more usable across more projects).
@JounQin thanks for the offer, but we have a lot of coordination we'll need to do to get this done in time for the alpha, so I'll need to keep this one.
I'll have to give it a try in eslint@9.0.0-alpha.0