RFC: oxlint support ESLint v9 flat configs

[DonIsaac]

https://x.com/anthonysheww/status/1820885098134434237?s=46&t=SqAn_WFH4gORgiw6KZBoMw

For the most widespread adoption, oxlint should be as close to a drop-in replacement for ESLint as possible. This means we should support their config files in all of their flavors. This RFC is to start a conversation on if/how we should approach this.

We already support (most) .eslintrc.json configs, so this is focusing on JS configs

Possible Approaches

There's a few different ways we could tackle this:

1. Run a script in Node or Bun that loads the config, evaluates the JavaScript, and prints the final config object to stdout. Oxlint could then parse it from there. This option would add a lot of overhead (spawning a process, running node, evaluating javascript, etc) but would require zero extra work from end users.
2. Add a migration command (e.g. oxlint migrate -c eslint.config.json) that performs step 1 and saves the output to an oxlint-compatible file. This cuts down on overhead, but adds extra work for the end user
3. A combination of the two, where it's migrated automatically when run for the first time

Open Questions:

1. Should we support v8 nested configs?
2. Should oxlintrc.json files be extendable?

[Boshen]

1. Run a script in Node or Bun that loads the config, evaluates the JavaScript, and prints the final config object to stdout. Oxlint could then parse it from there. This option would add a lot of overhead (spawning a process, running node, evaluating javascript, etc) but would require zero extra work from end users.

[Boshen]

2. Add a migration command (e.g. oxlint migrate -c eslint.config.json) that performs step 1 and saves the output to an oxlint-compatible file. This cuts down on overhead, but adds extra work for the end user

[jfmengels]

This. And it could be a migration command external to oxlint. Otherwise you may need to maintain it for longer than you'd care for, removing support would be a breaking change for the tool.

[Boshen]

3. A combination of the two, where it's migrated automatically when run for the first time

[overlookmotel]

This would be tricky I think. If you do it automatically the first time, I imagine users would expect behavior of oxlint to be updated when config changes.

But if eslint.config.js imports or requires other files, to check whether the config has changed and the "migrated" version is out of date, it's not as simple as just hashing that file and comparing to last seen. You'd also need trace all the file's dependencies, and check them all for changes too.

[overlookmotel]

I suppose you could run eslint.config.js in NodeJS with a custom loader which records the paths of all files which are imported/required and their last mod timestamps. Then to check nothing in config has changed on next run, check the last mods of those files against the "last seen" list. Still complicated, but maybe just about viable.

[DonIsaac]

4. Support option 1 & 2, then print a message to the console suggesting they run a migration step

[lachlancollins]

I've inadvertently opened issue #4776 which is relevant to this discussion - ideally, I think the Oxlint config should be written in a format that is extendable. I would argue that a JS-based config file (e.g. oxlint.config.js) makes this easier to handle than a JSON-based config, but I don't think this necessarily needs to mirror ESLint's flat config format.

I think that a script to migrate ESLint config to Oxlint config (whatever format this ends up as) would be preferred. I'd like to use Oxlint and ESLint in combination, where ESLint will continue to check unsupported rules by using eslint-plugin-oxlint. In this situation, it wouldn't make sense to share the ESLint config with Oxlint.

[DonIsaac]

Another relevant issue: #3217

[DonIsaac]

oxc-project/backlog#87

[markEHVN]

Relevant oxlint support ESLint v9, I think we do not need do this feature. I am migrating ESLint v8 to v9 then I am so struggling but when I migrate ESLint v8 to oxlint, I feel so happy (expect oxc extension, I have a question at here.
From above reason, I think we should support people convert from ESLint v8 to oxlint smoothly rather support ESLint v9 for now.
Migrate ESLint v8 to oxlint will help oxlint's community quickly increase because ESLint v8 -> ESLint v9 so struggle.

[JustFly1984]

I think there should be support for both eslint configs, for me - I'm stuck with eslint 8, cos frameworks require eslint 8, and slow to upgrate. I have PRs prepared to enable eslint 9, then vite will support eslint 9, and cloudflare workers will support eslimt 9.
Meanwhile I just can't update. Even eslint-plugin-oxlint went 9 a week or so ago, breaking my setup on dependency update, so I had to revert it. But at the point then vite switches to eslint 9 or oxlint, would love to be able to migrate keeping eslint-plugin-oxlint.

[Sysix]

Meanwhile I just can't update. Even eslint-plugin-oxlint went 9 a week or so ago, breaking my setup on dependency update, so I had to revert it.

eslint-plugin-oxlint should work again with eslint v8 in version 0.11.1. If not, please create an issue

[JustFly1984]

@Sysix It works great with eslint 8 config again! Thank you