Skip to content

Reducing tsgolint Runtime by Consolidating TypeScript Programs #587

@no-yan

Description

@no-yan

Note

Disclosure: I used some AI tools: Gemini and ChatGPT for reviewing my draft and writing English.

Currently, tsgolint creates a Program for each tsconfig.json. As a result, common modules are compiled several times. In large repositories like Kibana (with 1200 tsconfig.json files), this leads to massive duplication of the module graph.
If we can compile less, larger Programs (based on actual entry points), we can reduce execution time.

Current Bottlenecks

Based on profiling on aws/aws-cdk (with 170 tsconfig.json files) , the time is distributed as follows:

  • GC (30%)
  • Compiling (25%)
  • Rule Type Checking (15%)
  • AST Visitor (5~10%)

The dominant costs are GC and compilation, which strongly suggests large numbers of duplicated ASTs, symbols, and type graphs living simultaneously.

How to identify "Entry Point" tsconfigs?

This is a hard problem. For example, packages/shared-config/tsconfig.json is obviously not an entry point, but we cannot determine it with a few lines of code.

It would be good if, when the user specifies entry points via arguments or configuration, we respect them.
Otherwise, we can implement the followings:

  • DAG + Topological sort
  • consider composite: true as an entry-point for project reference

Given large repositories generally have own build / resolution layer, It is more realistic that "offering API to choose entrypoints for users" than "tsgolint infers everything".

Related: #295

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions