Open MichaelDeBoey opened 10 months ago
Unless that plugin has support for the same eslint and node range as this plugin, i don’t think that’s necessarily the best choice.
This plugin: https://github.com/jsx-eslint/eslint-plugin-react/blob/ca162fdc5dc37f9f3447640a5a14a91daf73ea47/package.json#L80-L85
{
"engines": {
"node": "^16.0.0 || >=18.0.0"
},
"peerDependencies": {
"eslint": ">=8.40.0"
}
}
Which means stylistic has much more narrow range (which makes sense as the rules where migrated in eslint 8.40.0, so no point in using stylistic in earlier versions)
The point would be so an eslint 7 user, eg, could migrate to stylistic without having to upgrade eslint at the same time, but sure, I'm not suggesting stylistic needs to make a change - it's just a reason i wouldn't want to screw over users of this plugin who would be unable to use stylistic.
@ljharb it would actually be better to deprecate those rules and disallow changes to them here, but keep them for some time - just as eslint does
That's something to consider, but in the meantime it'd be good to run our tests for those rules, on stylistic's rules, so we can be sure they're actually equivalent.
@antfu has merged https://github.com/eslint-stylistic/eslint-stylistic/pull/17, so I guess we can safely deprecate all stylistic rules now
In a next major release, we could remove these rules as well if we want