Repository: TypeScript
Issue: [Build Performance] Including `yup` adds 3 seconds to lib type-checking
Labels: Needs Investigation

# Bug Report

In our (private) typescript project that utilizes composite projects, we've been struggling with increasing compile times as more projects have been added. I took a stab at investigating this based on the [Performance Tracing Docs](https://github.com/microsoft/TypeScript/wiki/Performance-Tracing). Ultimately I found that consuming `yup` adds ~3s to each package build (on an M1 MBP). Given we have 100+ composite projects in the repo (not all of which are impacted, since not all import `yup`), this starts to stack up as a non-trivial increase to build times.

This can be mitigated by setting `skipLibCheck` to `true`, but ideally this would be false for complete validation of downstream types.
<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms
performance yup lib type checking

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, and I reviewed the FAQ and found nothing applicable

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBATwK5jgMyhEcDkyw4CwAUCQKYAeks6SAdgMYzAR1wxkDOMAYvUyzoAKAJQAuOADcIwACZwA3iTgq4DVt0QoAyjCjA6AczgBeLWAB03fUdHLV6upwgAbMhZcRDQ-LpuGRAG4SAF8gA)
The above playground link isn't overly useful given this is a performance bug, I've also prepared a minimal repro. https://github.com/berickson1/Playground/tree/master/type-checking-perf

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
import yup from 'yup'

export function testFunction(): void {
    const yupString = yup.string()
    console.log(yupString);
}
```

### 🙁 Actual behavior
Project compile time went from sub-second to over 3s on an M1 MBP to a single project. When using composite projects, this has a larger impact for every package that includes `yup`.
![trace json (2 MB) - Perfetto UI 2021-11-18 at 10 20 26 AM](https://user-images.githubusercontent.com/1418465/142474141-5facbdb7-7dd4-4c61-be82-500cd1a086e4.jpg)

Trace ZIP: 
[trace.json.zip](https://github.com/microsoft/TypeScript/files/7565129/trace.json.zip)


### 🙂 Expected behavior
<!-- What you expected to happen instead, and why -->

Project compile sees a trivial increase when including `yup`. This could either be managed by 1) improving peformance of type-checking or 2) leveraging a shared in-memory cache for node_module lib types across composite builds