-
-
Notifications
You must be signed in to change notification settings - Fork 43
Description
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: trueas 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