Rule promotion v13

[Conaclos]

I propose to promote the following rules for the v13.0:

A11y

• useHeadingContent

Correctness

• useIsNan

Complexity

• noForEach

Alternatively noForEach could be placed in the Style group. Any opinion?

Style

• noConsoleLog
• useLiteralKeys
• useSimpleNumberKeys

Alternatively we could also move useLiteralKeys and useSimpleNumberKeys in Compleixty. Any opinion?

Suspicious

• noDuplicateJsxProps

---

I propose removing the following rule:

• useCamelCase (replaced by useNamingConvention).

---

I propose making recommended the following rules:

• noUselessFragments
• noRedundantUseStrict
• useExponentiationOperator

--

I have some difficulty to make sense of the Complexity group in face of the Style group.
For instance, noArguments, noCommaOperator, useExponentiationOperator, and more are in STyle. However, they could also be in Complexity.

[ematipico]

Complexity, from clippy

group offers lints that give you suggestions on how to simplify your code. It mostly focuses on code that can be written in a shorter and more readable way, while preserving the semantics.

Style, from clippy

group is mostly about writing idiomatic code. Because style is subjective, this lint group is the most opinionated warn-by-default group in Clippy.

Also, if a rule can't provide a code action or can't suggest an alternative to some syntax, it can't be style or complexity.

---

Thank you for opening the discussion. Here's some feedback:

• noConsoleLog should be a suspicious rule, it's not about styling but something that might be wrong; Unless you're working inside a logger, the console might be wrong;
• useLiteralKeys, should be complexity
• useSimpleNumberKeys, should be complexity. The name of the rule is about writing simpler code 😄
• noForEach that's a tough one because in the description, we describe different aspects (debugging, performance and readability). Personally, I would put it under suspicious because most of the time you'd want to use a loop instead, and that's a sign of an error; also complexity can work;
• noArguments, I would say suspicious but also complexity fit
• noCommaOperator, suspicious because it might lead to an error and we can't provide a code action/suggestion

I agree with rest of the proposals