Support eslint flat config

[OlivierZal]

No description provided.

[ljharb]

it'd be great to have some kind of test that this actually works, perhaps with a test fixture project that uses the flat config, and we run eslint on it and assert on the output?

[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 eslint/eslint#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.

[ljharb]

Obviated by #3018.