Consider detecting the eslint-prettier-config when migrating

[connorshea]

When running the migrate script, it might be worth considering whether the user has the prettier config package in their package.json (or however you want to check it).

It disables a lot of the styling/formatting-related lint rules that ESLint and its plugins provide, to avoid conflicts with prettier. You can see the list of rules here.

And since oxlint doesn't intend to support any of those stylistic rules, as part of the migration script we could opt to separate these stylistic rules when listing unsupported rules. And then communicate to the user "if you use the eslint-prettier-config, these rules were already disabled because they conflict with prettier. So if you use prettier (or eventually oxfmt), you can just ignore that these rules are unsupported by oxlint".

I think that would help make migrating simpler, especially for complex setups where they want to ensure that they can avoid losing the lint rules they've got set up. And this config is very popular, with 26m weekly downloads, so I'd expect this to be a fairly common use-case.

This issue is inspired by attempting the migration on the repository at my job, and needing to figure out how many of the lint rules actually mattered, since our ESLint setup is pretty complex and used the (now basically dead) Airbnb ESLint config. I think it may be worth logging which unsupported ESLint rules are deprecated for the user as well, so they know they may not want to get those ported over to oxlint anyway.

[Sysix]

The reporting is probably too aggressive. The rules should be deactived by the script.
When the script finds the first unsupported rule declaration, it already reports, even if it gets later removed again.

It needs to hold the reports for each category and category-entry.
The "reporter":

oxlint-migrate/bin/oxlint-migrate.ts

Lines 59 to 64 in a5496ee

	const options: Options = {
	reporter: console.warn,
	merge: !!cliOptions.merge,
	withNursery: !!cliOptions.withNursery,
	typeAware: !!cliOptions.typeAware,
	};

[connorshea]

The only concern I have with that change would be for complex configs that have multiple config objects, where you enable a rule for one part of the codebase but disable it for others. As long as you can consistently detect that, that'd definitely be a good change

[connorshea]

I don't see an easy way to fix the logs to only print at the end, because of how we're throwing away non-recognized rules and performing merges at the end right now 🤔 I'll need to think on it