From looking through https://eslint.org/docs/latest/extend/custom-rules, I don't think it's out of the question that oxlint could support most (if not all) ESLint plugins out of the box with a JS-side ESLint-compatible plugin runner. I also think it could likely be reasonably fast by leveraging AST transfer with lazy deserialization.
Putting aside for the moment the question of how it'd be implemented, performance, and how much work to do it...
The question is: Is this something we would like to support, if it was feasible to?
In broad terms, I see the arguments for/against as:
For
Good way to support the "long tail" of many ESLint rules/plugins which are not popular, but are each essential to their user bases. These rules are not popular individually, but probably a lot of users use something that Oxc doesn't support natively. So in aggregate, would be useful to a lot of potential users. Would allow a large chunk of users to switch completely from ESLint to Oxc.
As Oxc gains popularity, we can expect to be besieged by requests "Can you please implement blah-blah-random-rule that I really need?" This would satisfy all those requests, without imposing any work on our side.
Against
Sizeable work to implement.
Would constrain internals of Oxc to a degree - we'd need semantic, for example, to do all the scope analysis that ESLint needs. There's a few bits ESLint does which are more than semantic does at present.
Alternative
My assumption is that we should provide some way to use linter plugins written in JS. But that doesn't mean we necessarily have to support ESLint plugins. We could provide our own JS API instead.
This would be easier for us, but of course not as convenient for users, for whom the ideal is just to switch from ESLint to Oxc and for it to "just work".
Notes
This is not an urgent question or (I think) something we should aim to do anytime soon. But am bringing up the question now as it'd be useful to know whether it's a long-term goal or not for e.g. #32.
From looking through https://eslint.org/docs/latest/extend/custom-rules, I don't think it's out of the question that
oxlintcould support most (if not all) ESLint plugins out of the box with a JS-side ESLint-compatible plugin runner. I also think it could likely be reasonably fast by leveraging AST transfer with lazy deserialization.Putting aside for the moment the question of how it'd be implemented, performance, and how much work to do it...
The question is: Is this something we would like to support, if it was feasible to?
In broad terms, I see the arguments for/against as:
For
Good way to support the "long tail" of many ESLint rules/plugins which are not popular, but are each essential to their user bases. These rules are not popular individually, but probably a lot of users use something that Oxc doesn't support natively. So in aggregate, would be useful to a lot of potential users. Would allow a large chunk of users to switch completely from ESLint to Oxc.
As Oxc gains popularity, we can expect to be besieged by requests "Can you please implement blah-blah-random-rule that I really need?" This would satisfy all those requests, without imposing any work on our side.
Against
Alternative
My assumption is that we should provide some way to use linter plugins written in JS. But that doesn't mean we necessarily have to support ESLint plugins. We could provide our own JS API instead.
This would be easier for us, but of course not as convenient for users, for whom the ideal is just to switch from ESLint to Oxc and for it to "just work".
Notes
This is not an urgent question or (I think) something we should aim to do anytime soon. But am bringing up the question now as it'd be useful to know whether it's a long-term goal or not for e.g. #32.