new plugin: oxlint-config

[camchenry]

Note

The name of the plugin and the name of rules here is meant for discussion and could be changed in the future. The main point of this discussion is the approach itself, not the naming.

In #6988, we added support for exiting oxlint with an error code if there were unknown rules specified in the oxlint configuration. However, we found that this actually caused breakage in the real world (preactjs/preact has unknown rules specified). While it is good to warn users of unsupported rules, I don't think it should come at the cost of breaking CI by default. We should provide users with an opt-in/opt-out mechanism for lint rule configuration errors.

What if instead of reinventing diagnostics and error codes for oxlint config errors, we just reused the existing code for linter rules by creating an oxlint configuration lint plugin?

Problems to overcome

Parsing JSON

The current linter rule infrastructure is set up for parsing mainly JS/TS files, we would need to add support for JSON files and I'm not sure if oxc_parser supports that yet or not?

Adding config files to file walk

We would need to ensure that all oxlint config files get picked up by the file walker.

JSON code fixes

Similar to the parsing issue, I'm not sure if we have a syntax-aware way of doing code fixes within JSON files. We should be able to add auto-fixes for config rules.

Potential rules

• oxlint-config/no-unknown-rules: disallow rules that do not match any known rule in any plugin (disabled or otherwise)
• oxlint-config/no-disabled-rules: disallow rules that are part of disabled plugins
• oxlint-config/prefer-flat-config: (future) disallow config files below the root level
• oxlint-config/no-unknown-plugins: disallow plugins that do not match any known plugins
• oxlint-config/rule-denylist: deny specific rules from being used in any config file

[Boshen]

🤯 My experience with eslint config was exactly this, it needed a "linter" ...

btw I can send PR to preact to fix the rule configs.

I think it's either we break everyone (probably only a few) for one time, or do proper config linting.

In the mean time we can change the bail to warn for the next release.