I'm not really seeing the argument, right now they're also pushing unnecessary work onto everyone who uses `.eslintr.js` which already is a js config file. Yes, it is a small amount of work to fix, but it still means you have to go and read the changes and figure out what the breaking changes are to begin with.
My qualm isn't really that it's hard to fix it once you know it's broken, or to find it in the release notes, but rather that this change doesn't need to be breaking to begin with. I can understand changing the docs and changing the default value, I can also understand dropping the plaintext config file, but why also break every project that currently relies on `.eslintrc.js`? From the tooling side, it's one extra line to stat two file names rather than one.
It’s a hard thing to balance. One thing first, I’m not sure the config is (or always will be) the same across versions, so it could be that eslintrc configs can’t be parsed in the first place, even if they’re js.
I can also understand wanting to move entirely to one standard. Leaving remains of the old one, with over a decade of documentation about it all over the internet, could make remaining functioning artifacts harder to debug when searched for. For example, someone is using eslint v11 and they search something like “eslintrc.js not registering”, and heaps of the results they get pertain to irrelevant versions of the software. Sure there are ways around this for the searcher (and something like copilot will surely catch these things quickly), but that doesn’t mean eslint’s GitHub issues wouldn’t risk being inundated with this type of problem for years.
I agree with you too, though. I imagine they felt they’d given it enough time and warning, and they’d prefer to keep their internals cleaner and more consistent, and their documentation simpler as well. Weird gotchas like “oh also this really old type of file we don’t technically support can still be loaded” are a bad noise when people want signals.
