Replies: 2 comments
-
|
🤯 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. |
Beta Was this translation helpful? Give feedback.
-
|
Any further progress on this? I'm trying to migrate from eslint to oxlint but without a linter like this I have to go rule by rule and look up both the rule to ensure an oxlint equivalent exists AND that the config flags exist as well. It'd be so much simpler if I could just copy/paste my eslint config into my oxlint config and see which parts fail |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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
oxlintwith an error code if there were unknown rules specified in theoxlintconfiguration. However, we found that this actually caused breakage in the real world (preactjs/preacthas 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_parsersupports that yet or not?Adding config files to file walk
We would need to ensure that all
oxlintconfig 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 pluginsoxlint-config/prefer-flat-config: (future) disallow config files below the root leveloxlint-config/no-unknown-plugins: disallow plugins that do not match any known pluginsoxlint-config/rule-denylist: deny specific rules from being used in any config fileBeta Was this translation helpful? Give feedback.
All reactions