Rename linter groups

[ematipico]

Rome linter is designed to be cross language, which means that a rule should be able to work on different languages. An example are rules regarding a11y, where they work on JSX files and HTML files. If one day we will be able to support vue for example, these rules should for there as well. And so on.

Unfortunately this concept doesn't seem to be clear to the most, probably because we are not communicating this enough. I also believe this is unclear, to the staff team too, because of how we name the groups of linter rules.

For example, we have two groups called js and ts, and many people think that the rules under the js group will work only on JavaScript files and might not work on other files.

Then we have the group regex, which is not language related. And this causes more confusion.

My proposal is to not use names that are related to a language, unless we know in advance that a group of rules will work only for a specific language (or better, a framework). Instead we should use broader categories, like concepts. I think this will help to better divide the origin of our rules. These concepts should also be documented in our website, which is something we don't do nowadays. Using a concept will help us to come up with a description of these groups.

The group js can be renamed to correctness or bugs.

Rules under jsx should be moved under correctness. Mostly because we know that we have plans to enabled JSX by default in our parser.

Rules under ts should be renamed to types or something similar. Mostly because these rules will rule on TS file and declaration files.

[MichaReiser]

It's difficult for me to assess this proposal without seeing some concrete configuration use cases. For example, how would we support the use case where a user wants to use another linter for css, but rome for everything else? We should think about other use cases too and maybe write them down. Like user personas for rome.

I do like the idea of having an a11 group because this isn't a concern of a single language.

Groups like correctness seem to broad in my view. We would loose fine grained control. Would react rules fall in that group too? Does that mean they're enabled by default?

[MichaReiser]

One option might be to introduce a new dimension. There are rule sets that enable certain rules.

And rule sets can be overridden per language.

But I'm not sure how to fit a11 into this approach

[ematipico]

We should think about other use cases too and maybe write them down. Like user personas for rome.

Can you chime in with some example so we kick off the ball? Because I find difficult to start it.

Groups like correctness seem to broad in my view. We would loose fine grained control.

Any counter proposal? My main idea was to agglomerate rules around JS/TS and coding issue into one group. Language antagonistic. If a new language pops and we have to craft rules, we put these rules based on these groups. Names? I proposed one. Maybe scripting as Sebastian suggested? Another one like styling?

Would react rules fall in that group too? Does that mean they're enabled by default?

Rules that are framework/library related should have their own group.

[strager]

Does Rome need groups? Why not a flat hierarchy?

If Rome starts with no groups, can groups be added later if they turn out to be a good idea?

[ematipico]

I think they make sense in the long term design.

We will have a group of rules for react, for example. In the future I don't hide the fact that we could have groups around specific frameworks.

[ematipico]

UPDATE 9th of September

Here's a proposal.

Removal of groups that resemble languages, as they create confusion among users.

The proposal takes inspiration from clippy and proposes their categories

New groups

• correctness
• style
• a11y
• nursery

correctness

This group should include all those rules that are meant to prevent possible bugs and misuse of the language.

• noArguments
• noAsyncPromiseExecutor
• noCatchAssign
• noCompareNegZero
• noDebugger
• noDelete
• noDoubleEquals
• noDupeArgs
• noEmptyPattern
• noExtraBooleanCast
• noFunctionAssign
• noImportAssign
• noLabelVar
• noShadowRestrictedNames
• noSparseArray
• noUnnecessaryContinue
• noUnsafeNegation
• noUnusedTemplateLiteral
• useBlockStatements
• useSimplifiedLogicExpression
• useSingleCaseStatement
• useSingleVarDeclarator
• useTemplate
• useValidTypeof
• useWhile
• noCommentText
• noImplicitBoolean
• noMultipleSpacesInRegularExpressionLiterals

style

Rules that focus mostly on making the code more consistent.

• useShorthandArrayType
• noShoutyConstants
• useSelfClosingElements
• noNegationElse

a11y

Rules to prevent errors in the a11y space.

We don't have rules that fall under this group

nursery

Rules that are being written, and might cause false positives or errors.

• noUnreachable (formerly noDeadCode)
• noUnusedVariables
• useCamelCase

Disable linter by language

It seems that this came up few times, although I am not sure if we should implement this right away or wait until we have multiple lintable languages. At the time of writing, we have only one language that is lintable, which is javascript.

A possible proposal would be to add a new flag inside our configuration:

{
	"javascript": {
		"linter": {
			"enabled": false
		}
	}
}

This would be applied to all the super languages that a parser supports.

This proposal is not meant for the linter only, because the same argument would be valid for the formatter too.

[Boshen]

In my opinion, a possible approach is to follow categories defined by rust clippy so we don't need to learn or invent anything new.

[ematipico]

In my opinion, a possible approach is to follow categories defined by rust clippy so we don't need to learn or invent anything new.

Yes, that's exactly what I was thinking. Yesterday I was study them and see if we could use the same in a web world.

[ematipico]

I updated the proposal, based on these comments and the discussion on discord

[MichaReiser]

What are your thoughts on moving noNegationElse to style?

[ematipico]

Makes sense!