☂️ Type-aware linter

[Conaclos]

Description

This umbrella issue tracks the development of type-aware lint rules.
We first motivate our decision to implement our own type synthesizer, and then present the type-aware rules we intend to implement. In a second section, we present preliminary design material that indicates the high-level direction we want to take.

Motivation

Multiple rules from TypeScript ESLint requires type information. Moreover, several linter rules could be enhanced by using type information.

TypeScript ESLint uses the TypeScript Compiler API to get types. This architecture has the advantage of using the TypeScript Compiler. However, it has several drawbacks:

• TSC is slow, and using the Compiler API makes the slowness even more noticeable.
  In fact, it is so slow that TypeScript ESLint provides presets with and without the rules that require type information.
• Biome and TSC use their own AST, which makes interoperability difficult.

This is why we think it is important to implement our own type synthesiser. If we have a fast type synthesiser, then we could enhance many lint rules with a marginal performance overhead. Note that we are not trying to implement a full-fledged type system or a type checker like TypeScript. Many attempt, even the most promising failed.

We believe that the Biome type synthesiser doesn't need to be perfect or handle complex TypeScript types. Even a rudimentary type synthesiser could be valuable to many lint rules.

Type-aware lint rules

A first design and implementation of the Biome type synthesiser aims to implement a preliminary version of the following rules:

• useAwaitThenable (await-thenable)

  Ensure that only thenable values are awaited. We could first target a rule that ensures that an awaited expression is a Promise. We could ignore values with an unknown type.

• noFloatingPromises (no-floating-promises)

  Ensure that a promise is handled (returned, awaited, ...).

• noForInArray (no-for-in-array)

  Ensure that for-in is not used on arrays.

• noDuplicateLiteralEnumMembers (no-duplicate-enum-values)

  Ensure that every enum member initialized with a literal expression is unique. This doesn't necessarlly requires a type system. We need to compute literal expressions.

Funding

To support this effort, please consider sponsoring Biome within our Open Collective or GitHub sponsorship.

We decide not to fund this issue with Polar.sh because it is a long term effort. Polar.sh is designed for short and medium term efforts. It set a deadline of 6 months to complete a task.

[MrTact]

Maybe the approach is to identify the most critical rules, and implement type inference just for the required types? E.g. the first two rules appear to be promise-related, so figure out that a given identifier is a promise. This should still be built on a forward-looking type analyzer architecture, but by constraining the scope, you can make the effort much more manageable, since you don't have to achieve parity with tsc (a fool's errand anyway, which you point out). This also means that, post an admittedly non-trivial chunk of groundwork, additional rules can be developed (and shipped, ideally!) incrementally.

If the duplicate enum rule doesn't require a type checker, it should probably be peeled off into its own issue. Seems like it's bundled here just because it comes from typescript-eslint.

[Conaclos]

I use tsc --noEmit && biome check . in my package.json. Can I drop tsc? What will I miss if I drop tsc?

Biome doesn't perform type checking and is not intended to do in the future.
Once this issue is resolved, Biome will be able to implement some rules from Typescript ESLint plugin that requires type information.

[junaga]

what about just shipping a default tsconfig.json, and then tell|ask|suggest Biome users in the docs to use it?

[testerez]

Note that we are not trying to implement a full-fledged type system or a type checker like TypeScript

Does it mean that types will be properly identified only when they are explicit? Or will Biome be able to follow complex type inferences?

[ericchase]

wanted to chime in about

• noFloatingPromises (no-floating-promises)

i think this is an extremely important rule. just this past week, i've forgotten to await async functions dozens of times. i had to pull in eslint with just 2 rules related to this to check my code. tsc is so horrendously slow.

i'm not really sure why these few specific rules need type awareness while other rules don't, but i would love to see these rules added!