Biome v1.3 Rule promotions (October release)

[Conaclos]

Biome has a special category named nursery. All rules of this category are unstable and experimental rules.
I propose to promote the following rules to a stable category because no bug was reported since the last minor release of Biome.

Rule promotion

Complexity

• noExcessiveComplexity
• noVoid

Performance

• noAccumulatingSpread

Style

• useCollapsedElseIf

Suspicious

• noConfusingVoidType
• noDuplicateJsonKeys
• noFallthroughSwitchClause
• noGlobalIsFinite
• noGlobalIsNan
• useIsArray

??

Should we stabilize useExhaustiveDependencies and useHookAtTopLevel? Or should we wait a config to declare the use of React? If we stabilize them, which category choose?

New Recommended rules

I propose to recommend the following rules:

• noAccumulatingSpread
• noConfusingVoidType
• noFallthroughSwitchClause
• noForEach

[ematipico]

• noVoid requires a slight rework in the diagnostic, we should tell the user what they should do;
• noAccumulatingSpread requires a slight rework of the diagnostic, we could suggest to methods such as .push, splice, etc.
• noConfusingVoidType, requires a slight rework of the diagnostic, it doesn't tell the user what they should do upon detection of the void type
• noDuplicateJsonKeys I would wait. This rule should be called noDeplucateKeys and "joined" with the name we have for the JS language. This means we need to change how we generate the documentation
• noForEach requires a slight rework of the diagnostic, add a note why a user should prefer for..of over forEach

Should we stabilize useExhaustiveDependencies and useHookAtTopLevel? Or should we wait a config to declare the use of React? If we stabilize them, which category choose?

They can be promoted but not recommended for the time being. We can work on the config later.

[Vivalldi]

noAccumulatingSpread requires a slight rework of the diagnostic, we could suggest to methods such as .push, splice, etc.

Is it possible to adjust the diagnostic based on a condition?

For [...acc, x] I'm thinking the diagnostic could be

Avoid the use of spread (...) syntax on accumulators. Use array.push or array.splice instead

And for { ...acc, [key]: value}

Avoid the use of spread (...) syntax on accumulators. Modify the object directly (object[key] = value)

[ematipico]

It's definitely possible, we have various rules where we change the messaging based on various conditions.

[Conaclos]

I could also rename noExcessiveComplexity to noExcessiveCognitiveComplexity

[ematipico]

Two rules should be promoted too:

• noDuplicatePrivateClassMembers
• noSuperWithoutExtends

These aren't lint rules but syntax rules. They are meant to catch syntax/semantic errors.