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.