✅ Deploy Preview for docs-rometools ready!

Name	Link
🔨 Latest commit	fb7aa10
🔍 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.

Parser conformance results on ubuntu-latest

js/262

jsx/babel

symbols/microsoft

ts/babel

ts/microsoft

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

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

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

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

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.

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?

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.

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

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)

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

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

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

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}

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.

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

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.