refactor(rome_js_analyze): reorganize lint rules into additional categories

[leops]

trafficstars

Summary

Closes https://github.com/rome/tools/issues/3719

This PR introduces new rule groups inspired by Clippy, and changes the group and recommended flag for a number of lint rules in preparation for v11.

New Groups

Perf

Rules catching ways your code could be written to run faster, or generally be more efficient.

The following rules have been moved to this group:

• noDelete

Suspicious

Rules that detect code that is likely to be incorrect or useless

The following rules have been moved to this group:

• noArrayIndexKey
• noAsyncPromiseExecutor
• noCatchAssign
• noCommentText
• noCompareNegZero
• noDebugger
• noDoubleEquals
• noDupeArgs
• noExplicitAny (+recommended)
• noFunctionAssign
• noImportAssign
• noLabelVar
• noShadowRestrictedNames
• noSparseArray
• noUnsafeNegation
• useValidTypeof

Existing Groups

Complexity

The following rules have been moved to this group:

• noMultipleSpacesInRegularExpressionLiterals
• noUselessFragments
• useFlatMap (+recommended)
• useOptionalChain

Correctness

The description of this group has been changed to only include rules that are strict about catching actual errors or dead code, while rules that only detect patterns that might be erroneous have been moved to the suspicious group.

The following rules have been moved to this group:

• noConstAssign (+recommended)
• useValidForDirection (+recommended)

Nursery

The noRestrictedGlobals rule has been downgraded to the nursery group as it only seems to be useful if it can be configured by the user, but it doesn't expose a way to specify this configuration yet.

The recommended flag has been removed for the noAccessKey since it's not stable yet.

Style

The following rules have been moved to this group:

• noArguments
• useSingleCaseStatement
• useWhile

The following rules are no longer recommended:

• noImplicitBoolean
• noNegationElse
• noShoutyConstants
• useBlockStatements
• useShorthandArrayType
• useSingleCaseStatement

Test Plan

Besides moving a number of snapshot tests around, I had to change a few tests that relied on the specific group of a rule or category of a diagnostic.

[netlify[bot]]

✅ Deploy Preview for docs-rometools ready!

Name	Link
🔨 Latest commit	fb7aa1035fc44d9daa9e8a424b18c9b8429b87f5
🔍 Latest deploy log	https://app.netlify.com/sites/docs-rometools/deploys/638dd22c39d5e00008402153
😎 Deploy Preview	https://deploy-preview-3908--docs-rometools.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[github-actions[bot]]

Parser conformance results on ubuntu-latest

js/262

Test result	main count	This PR count	Difference
Total	45879	45879	0
Passed	44936	44936	0
Failed	943	943	0
Panics	0	0	0
Coverage	97.94%	97.94%	0.00%

jsx/babel

Test result	main count	This PR count	Difference
Total	39	39	0
Passed	36	36	0
Failed	3	3	0
Panics	0	0	0
Coverage	92.31%	92.31%	0.00%

symbols/microsoft

Test result	main count	This PR count	Difference
Total	5946	5946	0
Passed	1757	1757	0
Failed	4189	4189	0
Panics	0	0	0
Coverage	29.55%	29.55%	0.00%

ts/babel

Test result	main count	This PR count	Difference
Total	588	588	0
Passed	519	519	0
Failed	69	69	0
Panics	0	0	0
Coverage	88.27%	88.27%	0.00%

ts/microsoft

Test result	main count	This PR count	Difference
Total	16257	16257	0
Passed	12397	12397	0
Failed	3860	3860	0
Panics	0	0	0
Coverage	76.26%	76.26%	0.00%

[Conaclos]

I am wondering if noArguments is really a stylistic rule. Complexity could be a better fit?

[leops]

I am wondering if noArguments is really a stylistic rule. Complexity could be a better fit?

It comes down to the definition of each group: complexity is for code that code be written in a simpler way, while style is for code that could be written in a more idiomatic way. The different between the two is really subtle in this case, but I think it's a slightly better fit for style

[ematipico]

The Perf group should be called Performance. Abbreviations should be avoided whenever possible.

[Conaclos]

The Perf group should be called Performance. Abbreviations should be avoided whenever possible.

I am wondering if several rules should follow the same path:

noDupeArgs -> noDuplicatedFunctionParameters noDupeKeys -> noDuplicatedObjectKeys

[jeysal]

noDupeArgs -> noDuplicatedFunctionParameters noDupeKeys -> noDuplicatedObjectKeys

Agree with avoiding abbreviations. I implemented noDupeKeys and didn't think much of it, but I wouldn't pick this name now that I think about it, it just came straight from ESLint.

I would suggest these names: noDupeArgs -> noDuplicateArguments noDupeKeys -> noDuplicatePropertyNames Arguments and parameters are not the same thing, it should keep being called arguments. I would avoid going for something overly specific, e.g. saying object keys might be confusing later if we also apply it to, say, records. Property names might be clearer than keys.

Discussion might be going out of scope though since this appears to be just about the groups. I can re-suggest this on another issue for a rule names cleanup. Might be good to get some consistency in now because there are still few rules and many still in nursery so it's all not too breaking.

[Conaclos]

Arguments and parameters are not the same thing

Could you develop about that?

Arguments could be confusing because of js implicit arguments variable. By the way, I assimilate arguments to actual parameters and I assimilate parameters to formal parameters.

If noDuplicateArguments is preffered over noDuplicateFunctionParameters, I should certainly rename noDefaultFunctionParameterLast to something like noDefaultArgumentLast?

[jeysal]

Arguments and parameters are not the same thing

Could you develop about that?

We're going a bit off topic in this PR 😅 but yeah so basically iirc arguments refers to something that a function takes and parameters to the values that you pass to it when you call the function, that then become concrete "instances" of the arguments for that function call. This is why I think it is called no duplicate arguments and not no duplicate parameters.

[MichaReiser]

Arguments and parameters are not the same thing

Could you develop about that?

We're going a bit off topic in this PR 😅 but yeah so basically iirc arguments refers to something that a function takes and parameters to the values that you pass to it when you call the function, that then become concrete "instances" of the arguments for that function call. This is why I think it is called no duplicate arguments and not no duplicate parameters.

It's the other way round. You pass arguments in a call to a function that is parametrised by function parameters

https://stackoverflow.com/a/156787

https://tc39.es/ecma262/#sec-parameter-lists

[jeysal]

Oops sorry, thanks for looking it up. Typed it on my phone yesterday from memory which was apparently wrong. In that case noDuplicateParameters is good. Funny that ESLint also got it wrong (probably naming was also not thought too much about there)

[Conaclos]

I could also suggest adding Function in the name, such as noDuplicateFunctionParameters, in order to distinguish them from generic parameters.

[leops]

I ended up renaming noDupeKeys to noDuplicateObjectKeys, and noDupeArgs to noDuplicateParameters. I didn't include Function in the latter with the rationale that the rule works on more than "Function" nodes (it also works on methods), and that we may eventually extend it to detect not just duplicated formal parameters but also generic parameters

[xunilrj]

Makes sense to have specific groups for frameworks? I would love to move useExhaustiveDependencies and useHooksAtTopLevel to a React specific group.

[calibre-analytics[bot]]

Comparing refactor(rome_js_analyze): reorganize lint rules into additional categories Snapshot #1 to median since last deploy of rome.tools.

	LCP?	CLS?	TBT?
Overall Median across all pages and test profiles	477ms  from 267ms	0.049  from 0.009	0ms no change
Chrome Desktop Chrome Desktop • Cable	477ms  from 267ms	0.044  from 0.005	0ms no change
iPhone, 4G LTE iPhone 12 • 4G LTE	243ms  from 240ms	0.082  from 0.009	0ms no change
Motorola Moto G Power, 3G connection Motorola Moto G Power • Regular 3G	1.18s  from 1.07s	0.049  from 0.009	0ms no change

1 page tested

 Home

Browser previews

Chrome Desktop	iPhone, 4G LTE	Motorola Moto G Power, 3G connection

Most significant changes

	Value	Budget
Total JavaScript Size in Bytes Chrome Desktop	1.33 MB  from 86.8 KB
Total JavaScript Size in Bytes iPhone, 4G LTE	1.33 MB  from 86.8 KB
Total JavaScript Size in Bytes Motorola Moto G Power, 3G connection	1.33 MB  from 86.8 KB
Cumulative Layout Shift iPhone, 4G LTE	0.082  from 0.009
Cumulative Layout Shift Chrome Desktop	0.044  from 0.005

_{17 other significant changes: Cumulative Layout Shift on Motorola Moto G Power, 3G connection, Number of Requests on Chrome Desktop, Number of Requests on iPhone, 4G LTE, Number of Requests on Motorola Moto G Power, 3G connection, JS Parse & Compile on Motorola Moto G Power, 3G connection, Total Page Size in Bytes on Chrome Desktop, Total Page Size in Bytes on iPhone, 4G LTE, Total Page Size in Bytes on Motorola Moto G Power, 3G connection, Total CSS Size in Bytes on Chrome Desktop, Total CSS Size in Bytes on iPhone, 4G LTE, Total CSS Size in Bytes on Motorola Moto G Power, 3G connection, Total Image Size in Bytes on Chrome Desktop, Total Image Size in Bytes on iPhone, 4G LTE, Total Image Size in Bytes on Motorola Moto G Power, 3G connection, Total HTML Size in Bytes on Chrome Desktop, Total HTML Size in Bytes on iPhone, 4G LTE, Total HTML Size in Bytes on Motorola Moto G Power, 3G connection}

_{Calibre: Site dashboard | View this PR | Edit settings | View documentation}

[ematipico]

Makes sense to have specific groups for frameworks? I would love to move useExhaustiveDependencies and useHooksAtTopLevel to a React specific group.

This is something we have discussed also on Discord. @MichaReiser suggested something different: having a specific place in the configuration where users can specify their framework (react, svelte, vue, etc.), and then Rome will enable all things related to that framework: lint rules, parsing quirks, formatting quirks, bundler quirks, etc.

[MichaReiser]

Have you performed any testing on the promoted rules on real-world projects like ESLint?

[leops]

Have you performed any testing on the promoted rules on real-world projects like ESLint?

I've tested the newly recommended rules (complexity/useFlatMap, correctness/useValidForDirection, suspicious/noExplicitAny and correctness/noConstAssign) on the ESLint repo and they are not raising any error. Also I don't think I mentioned it at the time but I had run a similar test when I enabled the recommended nursery rules on unstable builds already, so I had already removed the recommended flag for rules that had high false positive rates.