☂️ First batch of Linter Rules

[leops]

Description

This umbrella task aims to track the list of lint rules we need to implement in order to get the linter ready for release (aka. provide helpful hints and fixes in real world code)

This list was assembled by collecting lint rules from various linter projects (the Rome JS linter, ESLint and popular plugins, and some concepts from the Clippy linter for Rust that also apply to JS), but more specifically I prioritized rules that are part of the recommended configurations and can be automatically fixed (some rules with no auto fixes but that still provide useful errors are included at the end). I also purposefully excluded most styling-related rules, since we have a formatter for that, as well as most rules that rely on type information (mainly in the ESLint TypeScript rules) as type checking is not part of the plan for the initial release of the analyzer.

Note that while this is an umbrella issue aimed at tracking the implementation work, the list is also open to discussion: I may have accidentally missed some rules (also as of 02 Jun. 2022 I haven't gone over and included rules from the ESLint React plugin yet), and we may also decide that some of these rules aren't required for the initial release and can be de-prioritized.

If you want to contribute

1. make sure you understand the requirements of the rule you would like to implement;
2. comment on this very issue telling saying which rule you would like to implement;
3. create a new task issue and link to this very umbrella issue (a member of the team will eventually assign it to you);
4. open a PR;

Note: please make sure to comment the issue saying which rule you'd like to implement, this would allow better coordination between contributors. Failing to do so would penalize yourselves against contributors that had followed these simple guildelines

Note: follow the naming convention guidelines: https://github.com/rome/tools/blob/archived-js/CONTRIBUTING.md#naming-patterns

Fixable Rules

Rome JS

• noCompareNegZero #2647
  Disallow comparing against -0
  Example fix:
  1 >= -0 -> 1 >= 0
• 📎 noDebugger #2651
  Disallow the use of debugger
• noExtraBooleanCast #2660
  Disallow unnecessary boolean casts
  Example fix:
  if (Boolean(foo)) {} -> if (foo) {}
• 📎 noNegationElse  #2656
  Disallow negation in the condition of an if statement if it has an else clause
  Example fix:
  if (!true) {consequent;} else {alternate;} -> if (true) {alternate;} else {consequent;}
• noSingleCharRegexAlternatives #2754
  Disallow the use of single character alternations in regular expressions
  Example fix:
  /a|b/ -> /[ab]/
• noSparseArray #2652
  Disallow sparse arrays
  Example fix:
  [1,,2] -> [1,undefined,2]
• noUnnecessaryContinue #2746
  This rule detects continue statements that can be marked as unnecessary. These statements can be safely removed
  Example fix:
  loop: for (let i = 0; i < 5; i++) { continue loop; } -> loop: for (let i = 0; i < 5; i++) {}
• noUnsafeNegation #2747
  Disallow negating the left operand of relational operators
  Example fix:
  !1 in [1, 2] -> !(1 in [1, 2])
• 📎 noUnusedTemplateLiteral #2654
  Disallow template literals if interpolation and special-character handling are not needed
  Example fix:
  const foo = `bar`; -> const foo = "bar";
• useOptionalChain #2748
  Use optional chaining to manual checks
  Example fix:
  foo && foo.bar; -> foo?.bar;
• feat(rome_analyze): useBlockStatements #2658
  Prefer block statements to inline statements
  Example fix:
  if (x) x; -> if (x) { x; }
• useSimplifiedLogicalExpression #2749
  Discard redundant terms from logical expressions
  Example fixes:
  true && cond -> cond
true || cond -> true
null ?? exp -> exp
(!boolExpr1) || (!boolExpr2) -> !(boolExpr1 && boolExpr2)
  Possible addition:
  !(a === b) -> a !== b
• feat(rome_analyze): implement the useSingleCaseStatement rule #2648
  Enforces case clauses have a single statement
  Example fix:
  switch (foo) { case 1: foo; foo; } -> switch (foo) { case 1: { foo; foo; } }
• useSortedSpecifiers #2755
  Enforces the specifiers in import declarations are sorted alphabetically
  Example fix:
  import {b, a, c, D} from 'mod'; -> import {D, a, b, c} from "mod";
• useTemplate #2750
  Prefer template literals to string concatenation
  Example fix:
  foo + "baz" -> `${foo}baz`
• noCommentText #2751
  Comments inside children section of tag should be placed inside braces
  Example fix:
  <div>// comment</div> -> <div>{/** comment*/}</div>
• noImplicitBoolean
  Use explicit boolean values for boolean JSX props
  Example fix:
  <input disabled /> -> <input disabled={true} />
• useSelfClosingElements
  Prevent extra closing tags for components without children
  Example fix:
  <div></div> -> <div />
• noMultipleSpacesInRegularExpressionLiterals
  Disallow multiple consecutive space characters in regular expressions
  Example fix:
  / / -> / {3}/
• useShorthandArrayType #2744
  Prefer shorthand T[] syntax instead of Array<T> syntax
  Example fix:
  let a: Array<foo>; -> let a: foo[];
• useTsExpectErrorPrefer #2753
  Prefer @ts-expect-error to get notified when suppression is no longer necessary
  Example fix:
  // @ts-ignore -> // @ts-expect-error

[IWANABETHATGUY]

Would it be better if we use task or todo instead of markdown li to mark each analysis rule, currently contributor has no idea which rule has been implemented.

[ematipico]

@leops Rome classic used to define categories for lint rules (js, regex, ts, react, etc.). Is it something we are also doing here with this rewrite?

[IWANABETHATGUY]

@ematipico , Would you mind open task for

1. useBlockStatements
2. noNegationElse
3. noUnusedTemplateLiteral
4. noSparseArray
5. noCompareNegZero
6. noDebugger

and assgin them to me ?
Feel free to close tasks that i opened before.

[remmycat]

I'd like to take over noExtraBooleanCast :)

[IWANABETHATGUY]

@ematipico , would you mind assigning me the task useSortedSpecifiers ?

[ematipico]

@ematipico , would you mind assigning me the task useSortedSpecifiers ?

Sure, please open the issue first

[IWANABETHATGUY]

@ematipico , would you mind assigning me the task useSortedSpecifiers ?

Sure, please open the issue first

IIRC, you could convert the todo to a new issue, and after I finish the task, the checkbox will be automatically checked, maybe that would be a better way to manage the task?

[IWANABETHATGUY]

@ematipico , would you mind assigning me the task noImplicitBoolean?
#2699

[IWANABETHATGUY]

@ematipico , would you mind assigning me the task useSelfClosingElements?

[IWANABETHATGUY]

@ematipico , would you mind assigning me the task useFragmentSyntax?
#2712

[IWANABETHATGUY]

Sorry, I found original implementation need the https://github.com/rome/tools/blob/6b47011c5f3d5ed783855b821cdbc9cf1d687266/internal/compiler/lint/utils/react/doesNodeMatchReactPattern.ts#L25， getBinding which not support now, so just ignore me for now.

[IWANABETHATGUY]

@ematipico , would you mind assigning me the task noMultipleSpacesInRegularExpressionLiterals ?
#2716

[IWANABETHATGUY]

@ematipico , would you mind assigning me the task noUnsafeNegation
#2722

[Conaclos]

This could be nice to add some rules of denolint.

In particular, explicit-module-boundary-types. This is certainly a rule that will be enforced by TypeScript in declaration isolation mode. This is very close to type-first approach of flow.

[IWANABETHATGUY]

@ematipico, Would you mind assigning me the eslint task noEmptyPattern, in this page it should be no-empty-pattern?

#2730

[IWANABETHATGUY]

@ematipico , would you mind assigning me the eslint task noAsyncPromiseExecutor, in this page it should be no-async-promise-executor?

#2732

[IWANABETHATGUY]

@ematipico , would you mind assigning me the eslint task no-dupe-args?
#2735

[IWANABETHATGUY]

@ematipico , would you mind assigning me the task preferShorthandArraytype ?
#2744

[ematipico]

@ematipico , would you mind assigning me the task preferShorthandArraytype ?

@IWANABETHATGUY Please rename the rule to useShorthandArraytype

[IWANABETHATGUY]

Ok

[ematipico]

I am going to close this issue. We have implemented most of the rules, the ones that remain will be moved to #2743, with their requirements.

The rule useSortedSpecifiers is mostly a styling rule and it might be implemented in the formatter.