jsx-eslint / eslint-plugin-react

React-specific linting rules for ESLint
MIT License
8.99k stars 2.77k forks source link

Deprecate stylistic rules in favor of `@stylistic/eslint-plugin`/`@stylistic/eslint-plugin-jsx` #3671

Open MichaelDeBoey opened 10 months ago

MichaelDeBoey commented 10 months ago

@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

ljharb commented 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.

burtek commented 9 months ago

This plugin: https://github.com/jsx-eslint/eslint-plugin-react/blob/ca162fdc5dc37f9f3447640a5a14a91daf73ea47/package.json#L80-L85

Stylistic:

{
  "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)

ljharb commented 9 months ago

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.

burtek commented 9 months ago

@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

ljharb commented 9 months ago

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.