TypeScript: Slow compilation issues (40-50s) - --skipLibCheck not working

TypeScript Version: 3.8.3

Search Terms: --skipLibCheck slow compilation tsc

Code

Running tsc --listFiles --generateCpuProfile profile --skipLibCheck from the command line results in having the following output - which appears to be slowing compilation significantly. It appears as though it’s including multiple .d.ts files from my @types node_modules in the compilation. What sort of time should I be expecting this amount of files to compile in? Any help reducing the compilation time would also be greatly appreciated.

/home/user1/projects/projectName/node_modules/@types/semantic-ui-form/global.d.ts
/home/user1/projects/projectName/node_modules/@types/jquery/JQueryStatic.d.ts
/home/user1/projects/projectName/node_modules/@types/moment-timezone/moment-timezone.d.ts
.....etc

Extended diagnostics are:
Files:                         3022
Lines:                       410050
Nodes:                      1604064
Identifiers:                 555657
Symbols:                     804555
Types:                       254555
Memory used:               1220647K
Assignability cache size:     95587
Identity cache size:          13620
Subtype cache size:         4718477
Strict subtype cache size:     6378
I/O Read time:                0.10s
Parse time:                   1.78s
Program time:                 3.22s
Bind time:                    1.45s
Check time:                  39.98s
transformTime time:           1.39s
commentTime time:             0.56s
I/O Write time:               0.20s
printTime time:               5.02s
Emit time:                    5.02s
Total time:                  49.68s

my tsconfig is as follows:

{
  "compilerOptions": {
    "outDir": "./dist/",
    "extendedDiagnostics": true,
    "baseUrl": "src/",
    "module": "commonjs",
    "target": "es6",
    "jsx": "react",
    "allowJs": true,
    "allowSyntheticDefaultImports": true,
    "moduleResolution": "node",
    "esModuleInterop": true,
    "strict": true,
    "experimentalDecorators": true,
    "skipLibCheck": true,
    "lib": [
      "dom",
      "es2015",
      "scripthost",
      "es6",
      "es2016",
      "es2017"
    ]
  },
  "include": [
    "./src/**/*.ts",
    "./src/**/*.tsx"
  ],
  "exclude": [
    "node_modules",
    ".idea",
    ".storybook",
    ".git",
    "dist"
  ]
}

with my project folder structure being:

├── src
│   ├── folder1/....
│   └── folder2/.....
├── node_modules
│   ├── shouldNotBeCompiled1.d.ts
│   ├── shouldNotBeCompiled2.d.ts
│   └── shouldNotBeCompiled3.d.ts
├── dist

Expected behavior: Should not type-check any of the files inside node_modules during compilation Actual behavior: Appears to be including node_modules/@types during compilation - which is causing a compilation time of ~50s for project.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 28 (13 by maintainers)

Commits related to this issue

Detect comparisons between large unions or intersections If their multiplied size is greater than 1E7 (chosen based on the repro in #41517), then we'll expend a large amount of time and memory compar... — committed to amcasey/TypeScript by amcasey 4 years ago
Detect comparisons between large unions or intersections If their multiplied size is greater than 1E7 (chosen based on the repro in #41517), then we'll expend a large amount of time and memory compar... — committed to amcasey/TypeScript by amcasey 4 years ago
Detect comparisons between large unions or intersections (#41574) * Detect comparisons between large unions or intersections If their multiplied size is greater than 1E6 (chosen based on the repro... — committed to microsoft/TypeScript by amcasey 4 years ago

Most upvoted comments

Performance tool in its current state didn’t help me at all unfortunately. The best way to debug this (albeit tedious) - was to remove 50% of your repo at a time (ie delete) - recompile, and see whether there was a noticeable difference. Once you figure out which side of the repo is causing the issue, do a 50% delete on that and so forth.

This resulted in it narrowing down to a singular file, and you should then be able to apply the above fix (from previous posts) to solve your issue

NoPhaseNoKill on Dec 9, 2020

So I managed to fix the issue by doing this:

<Button>
    <Icon name={this.props.icon as any as SemanticICONS}/>
</Button>

The generate trace for this instance was not helpful, as the log file was coming out at at a whopping 1.5GB lol. Chrome basically was like “nope I ain’t having that”. I profiled it by myself, by deleting directories/files to narrow it down - which lead me to that line of code.

The one specific difference with this bug (maybe as opposed to others of similar nature) - is that the massive object literal is coming from a third party library (semantic-ui-react in this case). Not sure if this makes a difference when fixing the issue, but something to keep in mind when you guys roll out a fix.

edit: formatting

NoPhaseNoKill on Nov 16, 2020

Upgrading to 3.9.7 results in basically the same speed:

Files:                         2698
Lines:                       380456
Nodes:                      1438657
Identifiers:                 499827
Symbols:                     772615
Types:                       237792
Instantiations:              763693
Memory used:               1705486K
Assignability cache size:     85249
Identity cache size:          13293
Subtype cache size:         9399787
Strict subtype cache size:     4043
I/O Read time:                0.12s
Parse time:                   1.58s
ResolveTypeReference time:    0.04s
ResolveModule time:           0.93s
Program time:                 2.96s
Bind time:                    1.83s
Check time:                  35.41s
transformTime time:           1.51s
commentTime time:             0.46s
I/O Write time:               0.14s
printTime time:               4.80s
Emit time:                    4.80s
Total time:                  44.99s

NoPhaseNoKill on Nov 12, 2020