我不太确定如何将这个转化为可操作的内容。类型只是非常复杂。以下是 date.d.ts 的代码片段：

export interface RequiredDateSchema<TType extends Maybe, TContext extends AnyObject = AnyObject> extends DateSchema<TType, TContext, NonNullable> {
// Cheap half
defined(msg?: MixedLocale['defined']): DefinedDateSchema<TType, TContext>;
required(msg?: MixedLocale['required']): RequiredDateSchema<TType, TContext>;
optional(): DateSchema<TType, TContext>;
notRequired(): DateSchema<TType, TContext>;

// Expensive half
default<D extends Maybe<TType>>(def: Thunk<D>): If<D, RequiredDateSchema<TType | undefined, TContext>, RequiredDateSchema<Defined<TType>, TContext>>;
nullable(isNullable?: true): RequiredDateSchema<TType | null, TContext>;
nullable(isNullable: false): RequiredDateSchema<Exclude<TType, null>, TContext>;

}

注解掉 "expensive half" 可以节省大约 0.4 秒(!!),但很容易看出原因 -- 验证所有这些示例是否合法是一项巨大的工作。我们可能可以让它稍微快一点，但我们无法检查得足够快，以至于它不会对整体构建性能产生可测量的影响。即使从 3 秒提高到 0.3 秒，仍然会在多个构建中累积很多。

我们不可能在构建之间重用验证结果，因为组合构建中的每个项目可能具有不同的设置或引入不同的类型(实际上，在大多数构建中，后者几乎肯定是这种情况),这两者都可能影响任意库类型检查是否成功。

如果你正在拉取其他人发布到 npm 的 lib 文件，那么 skipLibCheck 只是一件非常非常安全的事情，我们普遍推荐它就是因为这个原因。

我亲眼看到过一些下游类型的类型断开，因为软件包升级而发生，所以为了安全起见，我们将其禁用。
我们的仓库中还有一些复杂的递归类型 - 因此在这里的改进可能会对其他人产生下游效益，但很难直接列举。我正在对我们的项目进行一些性能分析，以识别和改进热点。
话虽如此，我会继续设置 "skipLibCheck": true 来实现我们在构建中的一些收益。

@amcasey 和我讨论后的想法：

• 添加一个构建模式开关，使得每次构建操作只检查 .d.ts 文件一次，即使这可能并不正确(命名为 --skipLibCheckYolo 或其他名称)
• 以某种“环境”定义为基础，将项目分组(设置、相关的全局增强等),并假设它们的大小不会太大，一次性通过检查器传递多个项目。我们可以乐观地根据先前构建的 tsbuildinfo 进行分组，然后在某个假设无效时退出。有很多具有“许多太小的项目”设置的项目会从这个想法中受益匪浅，但以一种能够很好地摊销的方式实现起来非常困难，因为有很多信息需要计算“环境”。
• 我在输入这些内容时想到的一个子想法：我们可以让项目明确定义一个“队列”属性，表示“我保证与其他同一队列中的项目一起分组是安全的”。这将正确性的压力放在用户身上(当然是一种权衡),但可能可以在单独的遍历过程中静态验证( tsc --build --check-cohorts?)。

翻译结果为：我认为这两个选项中的任何一个都有助于我们的场景-我们的设置基本上是模板化的tsconfig文件(见下文),所以不应该包含任何其他类型。在上述选项中，我确实喜欢分组的概念-这样可以非常明确地表明行为是相互关联的(也许可以放置一个简单的检查器来验证同一组中的tsconfig.json文件是否一致)

顺便说一下，在4.6版本中，我们因为#46599而在yup上表现得更好。对于yup的已输入包的检查时间从4.5的5.0秒减少到4.6的1.5秒，减少了3倍多。

顺便说一下，在4.6版本中，我们对yup的处理效果要好很多，这得益于#46599。对于yup的检查时间，使用4.5版本时是5.0秒，而使用4.6版本时只需1.5秒。这比之前的3倍减少还要多。
我可以确认，设置skipLibCheck: false可以将我测量到的yup处理时间(约3秒)降低到大约600毫秒，这主要得益于使用了3个高亮显示的昂贵的.d.ts文件和"typescript": "4.6.0-dev.20211120",。