Support eslint flat config

[OlivierZal]

[aaarichter]

@OlivierZal any progress on this? you are a dependency to the airbnb styleguide which can't support eslint 9 & flat config yet

[OlivierZal]

Hi, I confess I gave up (too many dependencies) and don't use the airbnb config anymore...

[ljharb]

In that case, anyone who wants to continue this PR, please don't open a new PR - instead, comment here with a link to a branch or commit, and I can pull in your changes.

[vonBrax]

hey @ljharb , I added flat config support in my fork: https://github.com/vonBrax/eslint-plugin-import/tree/feat/flat-config.

There are however a few points to discuss.

I based my solution similar to https://github.com/ember-cli/eslint-plugin-ember, which I found when reading https://github.com/eslint/eslint/issues/18095.

The advantage is that it is backwards compatible, but not so ergonomic since one does need to individually import the necessary configs instead of just one default import, like here for example: https://github.com/vonBrax/eslint-plugin-import/blob/fbb21b08c344c1306f92d0b466b5c0b647bbbcca/tests/files/flat-config-typescript/eslint.config.js#L1-L2

The eslint recommendation is to rename the old configs by appending "-legacy" to their names. We then would need only a single import, but that would also probably be a breaking change and it would also require fixing all the failing tests.

Because this plugin apparently also parse files "manually", I had to include estree as a dependency since I eslint doesn't seem to externalize it, otherwise we would ran into the parserPath or languageOptions.parser is required is required. Wouldn't it be possible to somehow use eslint to do the parsing here and thus leave the parsing configuration up to the user (estree, babel, typescript, etc)?

I've included a few test cases alongside my changes, but since I'm not familiar with this project nor with writing eslint plugins, I'm not sure if I'm missing something here.

Let me know what you think. I'm also happy to open a PR since I took a very different path than what was initially proposed by this PR.

[ljharb]

Existing entrypoints must continue to work in places they work now. I'd rather force flat config users to use a new entrypoint than force eslintrc users to use a "legacy" one.

It would of course be ideal if we could delegate as much parsing as possible to eslint.

If your fork's added tests can be made to pass, that seems great! The important part is that every existing test must continue to pass, in order to not have a breaking change.

[error-four-o-four]

Hey there,

I was wondering if you could explain why you're trying to avoid breaking changes or point us to a reference or explanation? @ljharb

At the moment the whole eslint ecosystem has to resolve breaking changes due to v9. I'd argue that it's a good opportunity to stop supporting everything before v8. There will be no such opportunity in the near future again. (let it gooo 🎶)

thanks in advance

[ljharb]

@error-four-o-four That's been the case with every eslint major, and I haven't had to drop compat yet, I'm not sure why I should start now. Breakage is COSTLY - as you can see with eslint's own breakage. I refuse to inflict unnecessary cost on millions of users solely for expediency - that would be sociopathic.

[error-four-o-four]

https://github.com/un-ts/eslint-plugin-import-x/issues/24#issuecomment-1902271741

I apologize.

I haven't caught up with all the discussions yet and there's quite a lot to read.