1. compilerOptions - 编译配置

1.1. Projects 项目配置

1.1.1. incremental：增量编译

默认值： false

incremental配置可以启用增量编译，提高编译速度。

当incremental设置为true时，TypeScript编译器在第一次编译之后会生成一个存储编译信息的文件，第二次编译会在第一次的基础上进行增量编译，只需要编译改变的部分，从而可以大大提高编译的速度。

并且还需要设置 outDir 属性来指定输出目录，因为增量编译需要能够访问先前的编译输出。

{
  "compilerOptions": {
    "incremental": true,
    "outDir": "./dist"
  },
}

1.1.2. composite：复合项目

默认值： false

当composite设置为true时，TypeScript编译器会生成一个outDir（默认为dist）用于输出编译后的文件，而不会污染项目的src目录。此外，复合项目中的每个包都可以独立地进行编译，生成自己的声明文件（.d.ts），而不会影响到其他包。这有助于维护大型项目中的代码结构和组织，使得每个包都可以独立地进行开发和测试。

1.1.3. tsBuildInfoFile: 增量编译信息文件路径

默认值："./.tsbuildinfo"

tsBuildInfoFile配置项的作用是指定buildInfo信息的保存位置。

TypeScript在执行源码编译时，会消费上次的buildInfo信息，并基于此完成增量编译，编译结束后会生成该次的构建信息，以供下次增量编译使用。通常情况下，buildInfo信息只会被TypeScript编译器消费，业务无需关注buildInfo文件存放位置，此时该配置项可以忽略不用配置。但在特殊场景下，若对buildInfo保存位置有强位置诉求时，就需要注意不同模块（尤其是在monorepo仓库中）的buildInfo的位置应该独立，否则可能会出现buildInfo的误消费或覆盖。

1.1.4. disableSourceOfProjectReferenceRedirect: 是否禁用项目引用源的重定向

默认值： false

disableSourceOfProjectReferenceRedirect的默认值为false，表示不禁用项目引用源的重定向。当设置为true时，将禁用由项目引用产生的程序集重定向，项目将使用自己引用的版本，而不是被引用的项目所使用的版本，这有助于更精细地控制版本冲突。

1.1.5. disableSolutionSearching：是否搜索解决方案（.sln）文件来自动添加项目引用

默认值： false

disableSolutionSearching配置项的作用是控制TypeScript编译器是否搜索解决方案（.sln）文件来自动添加项目引用。

当disableSolutionSearching设置为true时，TypeScript编译器将不会搜索当前目录或父目录中的.sln文件，也不会自动添加通过解决方案文件关联的项目引用。这意味着你需要在tsconfig.json中显式地列出所有需要编译的TypeScript文件或项目引用。

默认情况下，disableSolutionSearching的值为false，这意味着TypeScript编译器会自动搜索解决方案文件，并尝试添加通过解决方案文件关联的项目引用。这可以简化项目配置，特别是在大型项目中，其中可能有许多相互依赖的TypeScript项目。

然而，有时你可能希望禁用此功能。例如，在单项目构建系统中，你可能不想让TypeScript编译器搜索解决方案文件，或者你可能希望更精确地控制哪些文件或项目被包含在内。在这些情况下，你可以将disableSolutionSearching设置为true。

需要注意的是，即使disableSolutionSearching设置为true，你仍然可以在tsconfig.json中使用include、exclude和references等配置项来显式地指定要编译的文件和项目引用。这些配置项提供了更灵活的方式来控制编译过程。

1.1.6. disableReferencedProjectLoad：是否加载引用

默认值： false

disableReferencedProjectLoad 是 tsconfig.json 文件中的一个配置项，它用于控制 TypeScript 编译器是否加载引用的项目。这个选项通常用于优化构建过程，特别是在大型项目或具有许多相互依赖的 TypeScript 项目中。

当 disableReferencedProjectLoad 设置为 true 时，TypeScript 编译器将不会加载引用的项目。这意味着编译器只会考虑当前 tsconfig.json 文件中指定的文件和设置，而不会考虑其他项目中的 TypeScript 文件或配置。这可以加快编译速度，因为编译器不需要处理额外的文件和依赖关系。

然而，将 disableReferencedProjectLoad 设置为 true 也有一些限制。首先，你将无法直接访问或引用其他项目中的 TypeScript 文件。其次，如果引用的项目中有类型定义或其他重要的 TypeScript 功能，这些功能将无法在当前项目中使用。

通常情况下，disableReferencedProjectLoad 用于在特定场景下优化构建过程。例如，当你只想编译当前项目而不关心其他引用项目的类型定义或代码时，或者当你使用其他工具（如构建系统或 IDE）来处理引用项目的加载和类型检查时，你可以将 disableReferencedProjectLoad 设置为 true。

请注意，disableReferencedProjectLoad 并不常见，并且可能不是所有版本的 TypeScript 都支持这个选项。在使用此选项之前，建议查阅 TypeScript 的官方文档或更新日志，以确保你了解其用法和限制。

1.2. Language and Environment 语言和环境

1.2.1. target：编译目标版本

默认值： es5

target配置选项可以设置的值有es3、es5、es6、es2015、es2016、es2017、es2018、es2019、es2020、esnext等，例如，当target设置为es6时，TypeScript编译器会将TypeScript代码编译成符合ECMAScript
6规范的JavaScript代码。

1.2.2. lib：标准库

默认值： []

lib配置项用于指定编译器在编译 TypeScript 代码时应包含哪些库文件。

这些库文件提供了 TypeScript 运行时所需的一些声明和类型定义，确保 TypeScript 代码在编译成 JavaScript 后能够正确地与这些库进行交互。

lib 配置项通常包含一系列库文件名的列表，这些文件名对应于 TypeScript 标准库中的各个模块。例如，lib.dom.d.ts 包含了 DOM（文档对象模型）相关的类型定义，而 lib.es2015.d.ts 则包含了符合 ECMAScript 2015（ES6）标准的类型定义。

如果你不指定 lib 配置项，TypeScript 编译器将默认包含一些基本的库文件，如 lib.d.ts，但可能不会包含你需要的所有类型定义。因此，根据你的项目需求，你可能需要显式地添加或修改 lib 配置项来确保 TypeScript 编译器能够正确地识别和使用你需要的类型定义。

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "lib": [
      "es2015",
      "dom"
    ]
  },
  "include": [
    "src/**/*.ts"
  ],
  "exclude": [
    "node_modules"
  ]
}

示例中，lib 配置项被设置为一个数组，包含了 "es2015" 和 "dom" 两个值。这意味着 TypeScript 编译器将包含符合 ECMAScript 2015 标准的类型定义以及 DOM 相关的类型定义。

请注意，lib 配置项的值可以是库文件名的列表，也可以是预定义的库名称的列表。预定义的库名称（如 "es2015"）对应于一系列相关的库文件。你可以在 TypeScript 的官方文档中找到完整的预定义库名称列表。
注意：你可以通过逗号分隔多个库名称，也可以指定具体的库文件路径（如 "lib/typescript/lib.d.ts"）。不过，通常使用内建的库名称更为方便，因为 TypeScript 会自动找到对应的库文件。

以下是一些常用的 lib 配置项：

lib.d.ts
这是 TypeScript 的核心库文件，包含了 TypeScript 语言的基本类型定义，如 Array, Object, Function 等。
dom.d.ts
该文件包含了 DOM（文档对象模型）的类型定义，允许你在 TypeScript 代码中操作网页元素和浏览器 API。
es2015.d.ts (或 es2015.core.d.ts, es2015.promise.d.ts, 等)
这些文件提供了符合 ECMAScript 2015（也被称为 ES6 或 ES2015）标准的类型定义。es2015.d.ts 可能是一个组合了多个 ES6 模块的文件，而 es2015.core.d.ts, es2015.promise.d.ts 等则是更具体的模块。
es2016.d.ts, es2017.d.ts, es2018.d.ts, es2019.d.ts, es2020.d.ts, es2021.d.ts (以此类推)
这些文件分别对应着后续年份的 ECMAScript 标准，提供了新引入的 API 的类型定义。
esnext.d.ts
该文件包含了最新 ECMAScript 标准草案的类型定义。使用 esnext 可以确保你的项目总是包含最新的 ECMAScript 功能类型定义。
scriptHost.d.ts
该文件提供了在宿主环境（如 Node.js）中运行 TypeScript 脚本时的类型定义。
webworker.d.ts
该文件提供了 Web Worker API 的类型定义，允许在 TypeScript 中编写 Web Worker 脚本。

1.2.3. jsx：编译jsx语法

默认值： preserve

jsx 配置项用于指定如何处理 JSX 语法。JSX 是一种 JavaScript 语法扩展，通常用于 React 库中描述组件结构。TypeScript 支持 JSX，并允许你通过 jsx 配置项来选择不同的转换方式。

以下是 jsx 配置项的常用值及其含义：

"preserve" :
当设置为 "preserve" 时，TypeScript 编译器会保留 JSX 语法不变。这通常与 Babel 这样的工具结合使用，Babel 可以进一步转换 JSX 到 JavaScript。如果你使用 React，并且你的构建系统使用 Babel 来转换 JSX，你应该设置 jsx 为 "preserve"。

{
  "compilerOptions": {
    "jsx": "preserve"
  }
}

"react" :
当设置为 "react" 时，TypeScript 编译器会将 JSX 转换为 React.createElement 调用。这意味着你不需要 Babel 或其他工具来进一步处理 JSX，TypeScript 会直接为你完成转换。这种设置适用于那些不需要额外 JSX 转换步骤的项目。

{
  "compilerOptions": {
    "jsx": "react"
  }
}

"react-native" :
这个选项与 "react" 类似，但是它是专门为 React Native 设计的。它确保了 JSX 转换会考虑到 React Native 的特定环境。

{
  "compilerOptions": {
    "jsx": "react-native"
  }
}

"react-jsx" :
这个选项是 TypeScript 4.3 版本中引入的，用于支持新的 JSX 转换。这个转换允许更灵活的 JSX 使用，包括在函数组件中使用任何有效的表达式，而不仅仅是字符串字面量或表达式。这个选项通常与新的 jsxImportSource 配置项一起使用，来指定 jsx 转换的导入来源。

{
  "compilerOptions": {
    "jsx": "react-jsx",
    "jsxImportSource": "@emotion/react" // 或者其他提供jsx的库
  }
}

"preserve-props" (已废弃) :
这个选项曾经用于保留 JSX 属性名不变，但现在已经被废弃。应该使用 "preserve" 或 "react" 替代。

在配置 jsx 选项时，请确保你的项目构建系统和使用的库（如 React 或 React Native）与你的选择兼容。例如，如果你的项目使用 React，并且你使用 Babel 来转换 JSX，那么你应该选择 "preserve"。如果你直接使用 TypeScript，并且不需要 Babel，那么你可以选择 "react" 或 "react-jsx"。如果你正在开发 React Native 应用，那么 "react-native" 是正确的选择。

1.2.4. experimentalDecorators：是否启用装饰器

experimentalDecorators 配置项用于启用或禁用装饰器（decorators）的实验性支持。装饰器是一种特殊类型的声明，它可以被附加到类声明、方法、属性或参数上，以修改类的行为或增强其功能。

当 experimentalDecorators 设置为 true 时，TypeScript 编译器将允许你在代码中使用装饰器。这使得你可以使用装饰器来扩展或修改类、方法、属性或参数的行为，从而实现更高级别的编程模式，如依赖注入、元数据收集等。

以下是一个简单的例子，展示了如何在 TypeScript 中使用装饰器：

typescriptfunction logged(target: Function) {
  console.log(`${target.name} was called`);
}

@logged
class MyClass {
  myMethod() {
    console.log("Hello, world!");
  }
}

const myInstance = new MyClass();
myInstance.myMethod(); // 输出 "MyClass was called" 和 "Hello, world!"

在上面的例子中，@logged 是一个装饰器，它接受一个目标函数作为参数，并在该函数被调用时输出一条日志。通过将 @logged 附加到 MyClass 类声明上，我们扩展了类的行为，使其在每次被实例化时都会输出一条日志。

需要注意的是，由于装饰器目前仍然是实验性的功能，并且可能在未来的 TypeScript 版本中发生变化，因此在使用它们时需要谨慎。此外，装饰器通常与特定的库或框架一起使用，例如 Angular，这些库或框架提供了对装饰器的更高级别的支持和功能。

在 tsconfig.json 中启用 experimentalDecorators 的配置如下：

{
  "compilerOptions": {
    "target": "es5", /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', or 'ESNEXT'. */
    "experimentalDecorators": true, /* Enables experimental support for ES7 decorators. */
    // 其他编译器选项...
  },
  // 其他配置项...
}

确保在启用 experimentalDecorators 的同时，你也设置了合适的 target 选项，因为装饰器通常需要在较新的 ECMAScript 版本中才能正常工作。

1.2.5. noLib：是否包含默认库文件

noLib 选项用于控制是否包含默认的库文件（如 lib.d.ts）在编译过程中。lib.d.ts 是一个包含了 TypeScript 内置对象（如 Array、Date 等）声明的文件。

noLib 配置的作用如下：

自定义库文件：当你设置 noLib 为 true 时，TypeScript 编译器将不会自动包含默认的库文件。这允许你提供自己的 lib.d.ts 或其他自定义的库文件。这在你需要为特定的环境（如浏览器、Node.js、Web Worker 等）提供精确的类型声明时非常有用。
减少编译时间：在某些情况下，不包含默认的库文件可能会略微减少编译时间，尤其是当你的项目非常大时。
更严格的类型检查：不使用默认的库文件可能会导致更严格的类型检查，因为编译器不会自动为你提供内置对象的类型信息。这可能会暴露出一些之前未注意到的类型错误。
控制输出的声明文件：当生成声明文件（declaration 选项设置为 true）时，noLib 的设置也会影响生成的声明文件。如果 noLib 为 true，则生成的声明文件将不包含任何来自默认库的类型声明。

例如，如果你想为 Node.js 环境提供自定义的类型声明，并且不想包含默认的库文件，你可以这样配置 tsconfig.json：

{
  "compilerOptions": {
    "noLib": true,
    "types": ["node"] // 指定 Node.js 的类型声明
  }
}

在这个例子中，noLib 设置为 true，同时指定了 "types": ["node"] 来包含 Node.js 的类型声明。这样，TypeScript 编译器将使用你指定的类型声明，而不是默认的库文件。

请注意，当你设置 noLib 为 true 时，你需要确保提供了所有必要的类型声明，否则在编译过程中可能会遇到类型错误或缺少类型信息的问题。

1.2.6. TODO=====>待补充

1.3. Modules

1.3.1. module：编译后代码的模块系统

module配置选项用于指定编译后代码使用的模块化规范。

TypeScript编译器可以根据其规则对代码进行编译。module配置选项常用的值有"AMD"、"CommonJS"、"ES6"、"ES2015"、"UMD"、"System"、"IIFE"等，分别对应不同的模块化规范。例如，"CommonJS"对应的是CommonJS模块化规范，"ES6"对应的是ES6模块化规范。

1.3.2. rootDir：指定 TypeScript 源代码的根目录

默认值： process.cwd()，即项目根目录

rootDir 配置项用于指定 TypeScript 源代码的根目录。

这通常用于与 outDir 配置项一起使用，以控制编译后的文件（JavaScript 和声明文件）的输出目录结构。

rootDir 的主要作用是帮助 TypeScript 编译器理解源代码文件的结构，并将其正确地映射到输出目录中。这对于保持源代码和编译后文件之间的逻辑结构一致非常有用。

例如，假设你的项目结构如下：

/my-project
    /src
        /features
            feature1.ts
            feature2.ts
        /utils
            helper.ts
    /dist

你希望编译后的文件输出到 /dist 目录下，同时保持与源代码相同的目录结构。你可以使用 rootDir 和 outDir 来实现这个需求：

{
  "compilerOptions": {
    "rootDir": "src",  // 指定源代码的根目录为 "src"
    "outDir": "dist",  // 指定编译后文件的输出目录为 "dist"
    // 其他编译选项...
  },
  // 其他配置...
}

当你运行 TypeScript 编译器时，它会将 /src/features/feature1.ts 和 /src/features/feature2.ts 编译到 /dist/features/ 目录下，将 /src/utils/helper.ts 编译到 /dist/utils/ 目录下。这样，你就保持了源代码和编译后文件之间的相对路径一致。

如果没有设置 rootDir，TypeScript 编译器将使用包含 tsconfig.json 文件的目录作为根目录。在某些情况下，这可能导致输出目录结构与源代码结构不一致，特别是当源代码文件分散在多个子目录中时。通过设置 rootDir，你可以确保编译器正确地将源代码文件映射到输出目录。

1.3.3. moduleResolution：模块解析方式

默认值： node

moduleResolution 配置项的主要作用是确定 TypeScript 如何查找和解析模块。它有两个可能的值：

"node" ：这是默认的模块解析方式。当设置为 "node" 时，TypeScript 将使用 Node.js 的模块解析机制来查找模块。这意味着它将按照 node_modules 目录和 package.json 文件中的 main、module、exports 等字段来查找和解析模块。这种方式通常用于在 Node.js 环境中运行的 TypeScript 代码。
"classic" ：当设置为 "classic" 时，TypeScript 将使用传统的模块解析机制。这意味着它将按照 TypeScript 1.0 到 1.4 版本中的行为来查找和解析模块。这种方式主要用于与旧版本的 TypeScript 代码或库兼容。

在大多数情况下，推荐使用 "node" 作为 moduleResolution 的值，因为它与 Node.js 的模块解析机制保持一致，能够提供更好的兼容性和性能。然而，如果你的项目需要兼容旧版本的 TypeScript 代码或库，你可能需要将其设置为 "classic"。

1.3.4. baseUrl：解析非相对模块名称的基准目录

默认值： rootDir的路径

baseUrl 配置项用于指定解析非相对模块名称的基准目录。

换句话说，它定义了从哪个目录开始查找模块。这对于组织大型项目中的模块和代码结构非常有用，特别是当使用路径别名（path aliases）时。

当你有一个复杂的项目结构，并且想要通过简短的别名来引用其他目录中的模块时，baseUrl 就非常有用。你可以通过 paths 配置项来定义这些别名，而 baseUrl 则定义了这些别名的起始点。

例如，假设你的项目结构如下：

/project-root
    /src
        /features
            featureA.ts
        /utils
            helper.ts
    tsconfig.json

你可能想要通过别名 @utils 来引用 src/utils 目录下的文件。你可以这样配置 tsconfig.json：

{
  "compilerOptions": {
    "baseUrl": ".", // 基准目录是当前 tsconfig.json 所在的目录
    "paths": {
      "@utils/*": ["src/utils/*"]
    }
  }
}

在这个例子中，baseUrl 被设置为 "."，表示当前 tsconfig.json 文件所在的目录。然后，通过 paths 配置项，我们定义了一个别名 @utils，它映射到 src/utils 目录。这样，在 featureA.ts 文件中，你就可以使用 @utils/helper 来引用 helper.ts 文件，而不是使用相对路径 ../../utils/helper。

请注意，为了使路径别名能够正常工作，你还需要确保 moduleResolution 被设置为 "node"，并且你的编辑器或 IDE（如 Visual Studio Code）也配置了相应的路径别名，以便在编辑时能够正确地解析和导航到模块。

总之，baseUrl 配置项允许你指定模块解析的基准目录，并与 paths 配置项一起使用，以简化大型项目中模块的引用和导航。

1.3.4.1. baseUrl与rootDir的区别

baseUrl是解析非相对模块名称的基准目录，而rootDir是项目中的根目录。

baseUrl用于指定从哪个目录开始查找模块，它定义了模块的起始点，当你使用非相对路径来导入一个模块时（例如，使用别名导入），TypeScript会从baseUrl指定的目录开始查找这个模块；

而rootDir则指定了TypeScript编译器在编译时应该查找的根目录，它包含了项目中的所有源文件，它告诉TypeScript编译器在哪里可以找到你的源代码文件。

一般来说，在tsconfig.json中，如果不设置baseUrl，那么默认就是rootDir。

1.3.4.2. baseUrl与rootDir的作用

baseUrl：是解析非相对模块名称的基准目录；

rootDir：是项目中源代码的根目录。

1.3.5. paths：定义路径别名

paths 配置选项允许你为项目中的模块定义路径别名。这在大型项目中特别有用，因为它可以帮助你简化模块导入路径，避免使用冗长且复杂的相对路径。

paths 配置通常与 baseUrl 一起使用，baseUrl 指定了用于解析非相对模块名的基准目录。

下面是一个简单的例子来解释 paths 的作用：

假设你的项目结构如下：

/my-project
  /src
    /features
      featureA.ts
    /utils
      helper.ts
  tsconfig.json

在 featureA.ts 文件中，你可能想要导入 helper.ts 文件。通常，你可能需要使用相对路径来做到这一点，如：

import { helperFunction } from '../utils/helper';

然而，当你的项目变得越来越大，层级结构更加复杂时，这种相对路径可能会变得非常长且难以管理。

通过使用 paths 配置，你可以为 utils 目录定义一个别名，比如 @utils。首先，你需要在 tsconfig.json 文件中设置 baseUrl 和 paths：

{
  "compilerOptions": {
    "baseUrl": ".", // 基准目录是当前目录（tsconfig.json所在目录）
    "paths": {
      "@utils/*": ["src/utils/*"] // 为 'src/utils' 定义了一个别名 '@utils'
    }
  }
}

现在，在 featureA.ts 文件中，你可以使用 @utils 别名来导入 helper.ts：

import { helperFunction } from '@utils/helper';

这样，即使你的项目结构发生变化，只要 paths 配置保持更新，你的导入语句就不需要改变。这有助于保持代码的可读性和可维护性，特别是在大型项目中。

需要注意的是，paths 配置仅影响 TypeScript 编译器如何解析模块名。在运行时，你仍然需要确保相应的路径或别名被正确地解析和加载。这通常是通过配置模块打包工具（如 Webpack、Rollup 或 Parcel）来完成的。

1.3.6. rootDirs：设置同一虚拟目录

rootDirs配置项的作用是将多个目录放在一个虚拟目录下，运行编译后文件引入的位置发生改变，也不会报错。

rootDirs一般和composite、outDir一起使用，用来将多个tsconfig.json的配置合并到一个outDir目录下。需要注意的是，每个rootDirs指定的路径下，都需要有一个tsconfig.json配置文件，并且这个文件中的compilerOptions.composite需要设置为true。

它的作用主要是允许你将项目中的多个目录视为一个单一的、逻辑上的根目录。这在大型项目中特别有用，特别是当你希望构建的输出（即编译后的文件）具有特定的目录结构，而不是简单地反映源代码的目录结构时。

更通俗地说，rootDirs 可以让你告诉 TypeScript 编译器：“虽然我的源代码分散在多个目录中，但请将这些目录视为一个整体，并按照我指定的方式来组织编译后的输出。”

举个例子来说明 rootDirs 的用法：

假设你有以下的项目结构：

/my-project
  /src
    /app
      main.ts
    /libs
      utils.ts
  /dist

在这个例子中，src/app/main.ts 可能会导入 src/libs/utils.ts 中的一个函数。现在，假设你希望在编译后，所有的文件都被放在 dist 目录下，并且你希望使用相对路径来导入 utils.ts，而不是使用从项目根目录开始的绝对路径。

为了实现这一点，你可以在 tsconfig.json 中设置 rootDirs 和 outDir：

{
  "compilerOptions": {
    "outDir": "./dist",
    "rootDirs": ["./src/app", "./src/libs"]
  },
  "include": [
    "./src/app/**/*",
    "./src/libs/**/*"
  ]
}

在这个配置中：

outDir 告诉 TypeScript 编译器将编译后的文件输出到 dist 目录中。
rootDirs 告诉编译器将 src/app 和 src/libs 视为同一个根目录。

当 main.ts 导入 utils.ts 时，你可以使用相对路径，就像它们都在同一个目录下一样：

// 在 main.ts 中
import { someFunction } from './libs/utils';

尽管 main.ts 和 utils.ts 在源代码中位于不同的子目录中，但由于 rootDirs 的设置，编译器在编译时会将它们视为处于同一逻辑根目录下。这意味着在编译后的 dist 目录中，你可以使用相同的相对路径结构来引用这些文件，即使它们在物理磁盘上的位置不同。

总之，rootDirs 允许你更改源代码目录在编译后输出中的表示方式，这对于需要特定目录结构的大型项目或库特别有用。

1.3.7. typeRoots：指定声明文件搜索路径

typeRoots 选项用于指定类型声明文件（.d.ts 文件）的搜索路径。

这些类型声明文件通常包含了 TypeScript 第三方库的类型信息，以便在开发过程中提供类型检查和自动补全功能。

默认情况下，TypeScript 会查找全局安装的 npm 包中的类型声明文件，这些文件通常位于node_modules/@types 目录下。但是，有时你可能想要指定一个不同的位置来查找类型声明文件，或者你可能想要使用本地类型的声明文件而不是全局安装的声明文件。这时，你就可以使用 typeRoots 选项来指定这些额外的或替代的类型声明文件的路径。

typeRoots 可以是一个或多个目录路径的数组。当你指定了 typeRoots 后，TypeScript 会在这些目录中查找类型声明文件，而不是默认的 node_modules/@types 目录。

例如，如果你有一个本地的类型声明文件目录 local-types，你可以这样设置 typeRoots：

{
  "compilerOptions": {
    "typeRoots": ["./local-types", "./node_modules/@types"]
  }
}

在这个例子中，TypeScript 会首先在 ./local-types 目录下查找类型声明文件，如果在那里找不到，它会回退到 ./node_modules/@types 目录。

使用 typeRoots 的一个常见场景是当你想要使用本地开发的类型声明文件，而不是从 npm 仓库中安装的声明文件。这对于库的开发者来说特别有用，因为他们可以在开发过程中直接引用本地的类型声明文件，而不需要每次都发布到 npm 上。

注意：typeRoots 只影响类型声明文件的查找，不影响其他模块或文件的查找。对于模块和文件的查找，仍然使用 baseUrl 和 paths（如果设置了的话）来指定查找路径。

1.3.8. types：指定需要包含的类型声明文件

默认值： node_modules/@type

types 配置项用于指定需要包含的类型声明文件。当你使用第三方库时，这些库可能包含类型声明文件（.d.ts 文件），以便在使用 TypeScript 进行开发时提供类型检查和自动补全功能。

types 配置项允许你明确指定需要包含哪些类型声明文件。这在你需要排除某些不需要的类型声明文件或只包含特定的类型声明文件时非常有用。

例如，假设你正在使用一个名为 example-library 的第三方库，并且这个库提供了一个类型声明文件 example-library.d.ts。你可以在 tsconfig.json 中使用 types 配置项来指定包含这个类型声明文件：

{
  "compilerOptions": {
    "types": ["example-library"]
  }
}

这样，TypeScript 编译器就会包含 example-library.d.ts 文件中的类型声明，以便在开发过程中提供类型检查和自动补全。

需要注意的是，types 配置项通常用于指定全局安装的类型声明文件，这些文件通常位于 node_modules/@types 目录下。如果你想要包含本地项目中的类型声明文件，你可能需要使用 include 或 files 配置项来指定这些文件的路径。

此外，types 配置项还可以与 typeRoots 配置项一起使用，以指定类型声明文件的搜索路径。typeRoots 可以让你指定一个或多个目录，TypeScript 编译器将在这些目录中查找类型声明文件，而不是默认的 node_modules/@types 目录。

总之，types 配置项允许你明确指定需要包含的类型声明文件，以便在使用 TypeScript 进行开发时获得更好的类型检查和自动补全功能。

1.3.8.1. typeRoots和types的区别

typeRoots 是用来指定类型声明文件的搜索路径，而 types 是用来指定需要包含的具体类型声明文件的名称。
typeRoots 影响的是搜索路径，而 types 影响的是实际包含哪些类型声明文件。
你可以同时使用 typeRoots 和 types 来更精确地控制 TypeScript 编译器的类型声明文件搜索和包含行为。

1.3.8.2. typeRoots和types的作用

1.3.8.2.1. typeRoots

typeRoots 是用来指定 TypeScript 编译器搜索类型声明文件（.d.ts 文件）的目录。默认情况下，TypeScript 会查找 node_modules/@types 目录下的类型声明文件。但是，通过配置 typeRoots，你可以告诉 TypeScript 编译器去其他位置查找这些文件。

作用：

自定义类型声明文件的搜索路径。
可以包含多个目录，编译器会按照这些目录的顺序进行搜索。

例子：

假设你有一个项目，并且你希望 TypeScript 编译器从 custom-types 目录中查找类型声明文件，而不是默认的 node_modules/@types。你可以这样配置 tsconfig.json：

{
  "compilerOptions": {
    "typeRoots": ["./custom-types"]
  }
}

在这个例子中，TypeScript 编译器将只会从 ./custom-types 目录中查找类型声明文件。

1.3.8.2.2. types

types 配置项用于明确指定需要包含的类型声明文件的名称。当你只想包含某些特定的类型声明文件，而不是全局引入所有定义时，这个选项非常有用。

作用：

指定需要包含的类型声明文件的名称。
防止编译器自动包含所有可用的类型声明文件。

例子：

假设你只想包含 lodash 这个库的类型声明文件，你可以这样配置 tsconfig.json：

{
  "compilerOptions": {
    "types": ["lodash"]
  }
}

在这个例子中，TypeScript 编译器将只会包含 lodash 的类型声明文件，而不会包含其他任何库的类型声明文件。

1.3.9. TODO=====>待补充

1.4. JavaScript Support

1.4.1. allowJs：允许编译Javascript文件

默认值： false

allowJs 的作用是允许在 TypeScript 项目中编译 JavaScript 文件。

当 allowJs 设置为 true 时，TypeScript 编译器会编译项目中的 .js 文件，并将其转换为 .d.ts 文件（即声明文件）。这些声明文件包含了 JavaScript 文件的类型信息，使得 TypeScript 代码可以正确地引用和使用 JavaScript 文件中的代码。

这个选项在以下场景中特别有用：

在 TypeScript 项目中混合使用 TypeScript 和 JavaScript 文件：有些项目中可能同时存在 TypeScript 文件和 JavaScript 文件。通过开启 allowJs，可以确保整个项目都能被正确地编译和类型检查。
引入第三方 JavaScript 库：在开发过程中，经常需要引入第三方库。有些库可能没有提供 TypeScript 的类型定义，只有 JavaScript 文件。通过开启 allowJs，可以在 TypeScript 项目中正确地引入和使用这些库。

需要注意的是，当 allowJs 设置为 true 时，TypeScript 编译器会尝试为 JavaScript 文件生成类型声明。但由于 JavaScript 是动态类型的语言，生成的类型声明可能不完全准确。因此，在实际开发中，最好结合使用第三方库的类型定义文件（.d.ts 文件）或自己编写类型声明，以确保类型安全。

1.4.2. checkJs：允许检查Javascript文件

默认值： false

checkJs 配置项的作用是允许 TypeScript 编译器检查 JavaScript 文件中的类型错误。

当 checkJs 设置为 true 时，TypeScript 会尝试对 .js 文件进行类型推断，并在发现可能的类型错误时发出警告或错误。

这个选项对于那些希望逐步将 JavaScript 项目迁移到 TypeScript 的开发者来说非常有用。通过启用 checkJs，你可以在不改变文件扩展名的情况下，逐步为 JavaScript 代码添加类型注解，并利用 TypeScript 的类型系统来捕获潜在的错误。

例如，假设你有以下 JavaScript 代码：

function add(a, b) {
    return a + b;
}

add("5", 10); // 这将导致字符串和数字相加，而不是数字相加

如果你启用了 checkJs，TypeScript 编译器将能够识别出这个问题，并发出一个类型错误，因为字符串和数字的加法可能不是你预期的。

需要注意的是，checkJs 只会检查 JavaScript 文件中的类型错误，并不会自动将这些文件转换为 TypeScript 文件（即更改文件扩展名为 .ts）。此外，由于 JavaScript 是动态类型的，TypeScript 对 JavaScript 的类型推断可能不是完全准确的，因此在某些情况下可能会产生误报或漏报。

总结一下，checkJs 的作用是在 TypeScript 项目中对 JavaScript 文件进行类型检查，帮助开发者在逐步迁移或混合使用 TypeScript 和 JavaScript 时捕获潜在的类型错误。

1.4.3. maxNodeModuleJsDepth

默认值： 1

maxNodeModuleJsDepth 配置项用于指定在解析 Node.js 模块时，TypeScript 编译器应该深入到哪个级别的子目录中查找 JavaScript 文件（.js）进行类型检查。这个配置对于大型 Node.js 项目中管理依赖和类型检查非常重要。

当你有一个 Node.js 项目，并且使用了大量的 npm 或 yarn 包作为依赖时，这些包可能会包含 JavaScript 文件。如果你启用了 checkJs 选项，TypeScript 编译器默认会检查所有找到的 JavaScript 文件，包括那些深层的依赖。然而，这可能会导致编译器需要处理大量的文件，特别是当项目结构非常深或者有很多依赖时。

maxNodeModuleJsDepth 允许你设置一个数值，指定编译器在解析 Node.js 模块时应该深入的最大子目录层级。例如，如果 maxNodeModuleJsDepth 设置为 1，那么编译器只会检查直接依赖的 JavaScript 文件，而不会深入到更深层级的依赖中。这可以加快编译速度，减少不必要的类型检查，特别是在你知道深层依赖中的 JavaScript 文件不太可能包含类型错误的情况下。

这个配置选项的默认值是 1，意味着 TypeScript 编译器默认只会检查直接依赖的 JavaScript 文件。如果你想要更深入地检查依赖，你可以增加这个数值。然而，需要注意的是，增加这个数值可能会导致编译时间增加，因为编译器需要处理更多的文件。

总的来说，maxNodeModuleJsDepth 配置项提供了一种方式来平衡 Node.js 项目中 JavaScript 文件的类型检查范围和编译时间。通过合理地设置这个值，你可以确保重要的依赖文件得到类型检查，同时避免不必要的性能开销。

1.5. Emit

1.5.1. declaration：是否生成声明文件

declaration 配置项用于指示 TypeScript 编译器是否生成 .d.ts 文件，这些文件包含了 TypeScript 代码的类型声明。

当 declaration 设置为 true 时，TypeScript 编译器会为每个 TypeScript 源文件（.ts）生成一个对应的声明文件（.d.ts）。这些声明文件包含了源文件中的类型信息、接口、函数签名等，但不包含具体的实现。这使得其他 TypeScript 项目可以通过引用这些声明文件来使用你的库或模块的类型，而不需要直接引用源文件。

生成声明文件对于创建库或模块非常有用，因为它允许其他开发者在使用你的代码时获得类型提示和类型检查。同时，这也是发布 npm 包时常见的做法，因为 npm 包通常只包含源代码和声明文件，而不包含编译后的 JavaScript 文件。

下面是一个 tsconfig.json 文件中 declaration 配置项的示例：

{
  "compilerOptions": {
    "declaration": true,
    // 其他编译选项...
  },
  // 其他配置...
}

当 declaration 设置为 true 时，编译器会在 outDir（输出目录）指定的位置生成 .d.ts 文件。如果 outDir 没有被指定，那么声明文件将和源文件在同一个目录下生成。

需要注意的是，即使 declaration 设置为 true，编译器仍然会生成 JavaScript 文件（.js），除非你使用了 noEmit 选项。如果你只想生成声明文件而不生成 JavaScript 文件，你可以将 noEmit 设置为 true，但这样做的话，JavaScript 文件将不会被生成。

总之，declaration 配置项允许你控制 TypeScript 编译器是否生成类型声明文件，这对于创建库或模块以及发布 npm 包非常有用。

1.5.2. declarationMap：源代码映射

定义了 TypeScript 编译器如何编译你的 TypeScript 代码。declarationMap 是 tsconfig.json 中的一个选项，它涉及到源代码映射（source maps）和声明文件（.d.ts 文件）的生成。

具体来说，declarationMap 配置的作用如下：

生成声明文件（ .d.ts ）的源映射：当你为 TypeScript 项目设置 declaration 选项为 true 时，TypeScript 编译器会生成与你的 TypeScript 代码对应的声明文件（.d.ts）。这些声明文件包含类型信息，通常用于 IDE 的智能提示或其他 TypeScript 项目中。declarationMap 选项允许你为这些生成的声明文件生成源映射。
源映射（Source Maps） ：源映射是一种映射关系，它允许开发者在开发者工具（如 Chrome DevTools）中查看并调试编译后的代码，而看到的是原始源代码，而不是编译后的代码。这对于调试 TypeScript 代码特别有用，因为 TypeScript 代码在编译后会转换为 JavaScript。
方便调试：当 declarationMap 设置为 true 时，生成的声明文件（.d.ts.map）将包含与原始 TypeScript 源代码的映射关系。这意味着，当你在 IDE 或浏览器的开发者工具中查看或调试声明文件时，你可以直接看到原始的 TypeScript 代码，而不是编译后的 .d.ts 文件内容。

总的来说，declarationMap 配置的主要作用是帮助开发者更方便地调试 TypeScript 声明文件，确保开发者体验与源代码保持一致。

1.5.3. declarationDir：指定生成的声明文件目录

declarationDir 选项用于指定生成的声明文件（.d.ts）应该放置在哪个目录中。当你设置 declaration 选项为 true 以生成声明文件时，这个选项就非常有用，因为它允许你控制声明文件的输出目录。

默认情况下，生成的声明文件会与相应的 TypeScript 源文件（.ts）放置在同一个目录中。但是，通过 declarationDir，你可以指定一个不同的目录来存储所有的声明文件。

declarationDir 的配置作用有以下几点：

集中管理声明文件：如果你的项目有多个源文件，并且你想将所有的声明文件集中在一个目录下，declarationDir 可以帮助你实现这一点。这有助于保持项目结构的整洁，并使其他开发者更容易找到和使用声明文件。
避免声明文件冲突：在某些情况下，不同的源文件可能会生成具有相同名称的声明文件。使用 declarationDir 可以确保这些声明文件不会发生冲突，因为它们都会被放置在一个指定的目录中。
与构建系统集成：在一些构建系统中，你可能希望将生成的声明文件放置在一个特定的构建输出目录中。通过 declarationDir，你可以很容易地实现这一点，而无需手动移动或复制文件。

在 tsconfig.json 中，declarationDir 的值应该是一个相对于 tsconfig.json 文件的路径。例如，如果你希望将所有的声明文件放置在项目根目录下的 dist/types 目录中，你可以这样配置：

{
  "compilerOptions": {
    "declaration": true,
    "declarationDir": "dist/types"
  }
}

这样，无论你的源文件在哪里，生成的声明文件都会被放置在 dist/types 目录中。

1.5.4. outFile：输出文件的合并路径

outFile 选项用于指定编译后所有输出文件的合并路径。

当设置了 outFile 时，TypeScript 编译器会将所有编译后的输出合并到一个单独的文件中。

这对于生成一个单一的 JavaScript 文件非常有用，例如在一个浏览器环境中，你可能想要将所有 TypeScript 代码编译到一个单一的 bundle.js 文件中。

例如：

{
  "compilerOptions": {
    "outFile": "dist/bundle.js"
  }
}

1.5.5. outDir：输出文件的目录

outDir 选项用于指定编译后输出文件的目录。

当你编译多个 TypeScript 文件时，outDir 会告诉编译器将这些文件编译输出到哪个目录下。

默认情况下，编译后的文件会输出到与源文件相同的目录中，但通常我们会指定一个单独的目录来存放编译后的文件。

{
  "compilerOptions": {
    "outDir": "dist"
  }
}

1.5.5.1. outFile与outDir的区别

outFile 是将所有编译后的文件合并到一个单一的文件中。
outDir 是指定编译后文件的输出目录，不会合并文件。

1.5.5.2. outFile与outDir的作用

outFile 的作用是将多个 TypeScript 文件编译成一个单独的 JavaScript 文件，这在创建浏览器端的应用程序包（bundle）时非常有用。
outDir 的作用是将编译后的文件输出到一个指定的目录，以便于管理和部署，同时保持每个源文件的独立性。

通常，如果你需要构建一个库或者一个需要模块化加载的应用，你会使用 outDir。

而如果你正在创建一个浏览器应用，并且希望将所有代码打包到一个文件中，那么 outFile 会是一个好选择。

不过，这两个选项并不是互斥的，你可以同时设置 outFile 和 outDir，但通常只需要选择其中一个。

1.5.6. TODO=====>待补充

1.6. Interop Constraints

1.7. Type Checking

1.7.1. strict：开启严格检查模式

默认值： false

strict 用于启用或禁用一组严格的类型检查选项。当 strict 设置为 true 时，TypeScript 编译器会启用一系列严格的类型检查规则，这些规则有助于捕获更多的类型错误并提高代码的质量。

启用 strict 选项相当于同时启用了以下几个编译器选项：

strictNullChecks: 这个选项启用严格的空值检查。在严格的空值检查下，变量默认是不允许为 null 或 undefined 的，除非你明确地指定了它们的类型。此外，当你尝试访问一个可能为 null 或 undefined 的对象的属性时，编译器会报错。
noImplicitAny: 这个选项会导致编译器在表达式和声明上有隐含的 any 类型时报错。这有助于避免使用 any 类型作为回避类型检查的手段。
noImplicitThis: 这个选项在 this 表达式的类型为 any 时会发出错误。这有助于捕获 this 的错误使用，比如在一个箭头函数内部。
alwaysStrict: 这个选项设置生成的 JavaScript 代码总是在严格模式下运行。严格模式可以帮助 JavaScript 捕获更多的错误。
strictFunctionTypes: 这个选项启用严格的函数类型检查。在严格的函数类型检查下，函数参数的类型必须严格匹配，不能通过放宽参数类型来兼容不同的函数类型。
strictBindCallApply: 这个选项对 bind、call 和 apply 方法进行严格的类型检查。这意味着当你使用这些方法时，如果提供的参数类型不匹配，编译器会发出错误。
strictPropertyInitialization: 这个选项要求类的实例属性在构造函数中必须被初始化，否则会报错。这有助于避免使用未初始化的属性。
noImplicitReturns: 这个选项在函数或方法中如果控制流没有明确的返回值时会发出错误。这有助于避免函数意外地返回 undefined。
noFallthroughCasesInSwitch: 这个选项在 switch 语句中检测到 fall-through（即没有 break 语句的情况）时会发出错误。这有助于避免逻辑错误。

通过启用 strict 选项，你可以确保 TypeScript 编译器执行一系列严格的类型检查，这有助于在开发阶段捕获更多的错误，提高代码的可维护性和健壮性。

1.8. Completeness

1.8.1. skipDefaultLibCheck：跳过默认库检测

默认值： false

skipDefaultLibCheck 配置项的作用是跳过默认库的类型检查。

默认情况下，TypeScript 编译器会对默认库（通常是 lib.d.ts 文件，它包含了 TypeScript 的核心类型定义）进行类型检查。这对于确保类型的一致性非常有用，但在某些情况下，可能会导致编译时间增加，特别是当项目很大或者默认库中的类型定义发生变化时。

当你设置 skipDefaultLibCheck 为 true 时，TypeScript 编译器将跳过对默认库的类型检查。这可以加快编译速度，特别是在大型项目中，或者当你确信默认库的类型定义不会引入错误时。

然而，跳过默认库的类型检查也有潜在的风险。如果默认库中存在类型错误或不一致性，这些错误可能不会被捕获，从而导致在项目中使用这些类型时出现运行时错误。

因此，在使用 skipDefaultLibCheck 时需要权衡利弊。如果你的项目对类型安全有很高的要求，或者你不确定默认库的类型定义是否完全正确，最好保持该选项为 false。如果你确信默认库的类型定义是准确的，并且希望提高编译速度，那么可以考虑将其设置为 true。

1.8.2. skipLibCheck：跳过所有声明文件（.d.ts 文件）的类型检查

skipLibCheck 配置项的作用是跳过所有声明文件（.d.ts 文件）的类型检查。这可以提高编译速度，因为类型检查通常是一个相对耗时的过程，特别是当项目依赖大量的第三方库时。

当你在 TypeScript 项目中使用第三方库时，这些库通常会提供声明文件来描述它们的 API。然而，这些声明文件可能并不总是完全准确或最新的，有时候它们可能包含错误或遗漏的类型信息。如果这些声明文件存在问题，TypeScript 编译器在编译时会对它们进行类型检查，并可能报告错误。

skipLibCheck 配置项允许你跳过这些声明文件的类型检查，从而避免在编译过程中看到由第三方库引起的类型错误。这可以加快编译速度，并允许你专注于你自己的代码中的类型问题。

这里是一个 tsconfig.json 文件的示例，展示了如何使用 skipLibCheck 配置项：

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "skipLibCheck": true
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

在这个示例中，skipLibCheck 被设置为 true，这意味着 TypeScript 编译器将跳过所有 node_modules 文件夹中的声明文件的类型检查。

需要注意的是，虽然 skipLibCheck 可以加快编译速度并避免由第三方库引起的类型错误，但它也可能掩盖了某些实际的类型问题。因此，在使用 skipLibCheck 时，你应该谨慎地评估其风险和收益，并确保你的代码库中的类型仍然是正确的和一致的。

2. include：指定编译文件或文件夹

include 配置项的作用是指定哪些文件或文件夹需要被 TypeScript 编译器编译。

include 可以接收一个文件或文件夹路径的数组，这些路径下的 TypeScript 文件（.ts）和 JavaScript 文件（.js，需要配合 allowJs 选项）将会被编译器编译。通过 include 配置项，可以精确地控制哪些文件参与编译过程，从而避免不必要的编译，提高编译效率。

"include": [
    "src/**/*.ts",
    "src/**/*.d.ts",
    "src/**/*.tsx",
    "src/**/*.js",
    "src/**/*.jsx",
    "src/**/*.vue"
]

例如，如果有一个 TypeScript 项目，其中只有 src 目录下的文件需要被编译，那么可以在 tsconfig.json 文件中这样配置 include：

{
  "include": ["src/**/*"]
}

这表示 src 目录下的所有文件和子文件夹中的文件都将被编译器编译。注意，**/* 是一个通配符，表示任意文件或文件夹。

需要注意的是，include 和 exclude 配置项通常是一起使用的。exclude 配置项用于指定哪些文件或文件夹不需要被编译，这样可以进一步细化编译范围，排除一些不需要编译的文件，比如测试文件或配置文件等。

3. exclude: 指定排除在编译过程外文件或者文件夹

exclude 配置项用于指定一组文件或文件夹模式，这些模式匹配的文件或文件夹将被 TypeScript 编译器排除在编译过程之外，即使它们可能符合 include 配置项中指定的模式。

exclude 配置项是非常有用的，因为它允许你精细地控制哪些文件不应该被编译，特别是当你想要排除某些自动生成的文件、配置文件、测试文件或第三方库文件时。

例如，假设你有一个 TypeScript 项目，你希望编译 src 目录下的所有 .ts 文件，但是你不想编译任何在 node_modules 文件夹下的文件，因为这些是第三方库的代码。你可以这样配置 tsconfig.json：

{
  "compilerOptions": {
    // 编译器选项...
  },
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules/**/*"
  ]
}

在这个配置中：

include 配置项告诉编译器要包括 src 目录下的所有文件。
exclude 配置项告诉编译器要排除 node_modules 文件夹下的所有文件。

由于 exclude 配置项会覆盖 include 配置项，因此即使 node_modules 目录下的某些文件可能符合 src/**/* 的模式，它们也会被排除在编译之外。

exclude 配置项可以包含多个模式，用于排除不同类型的文件或文件夹。例如，你可能还想排除所有的日志文件或备份文件：

{
  "compilerOptions": {
    // 编译器选项...
  },
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules/**/*",
    "logs/**/*",
    "**/*.log",
    "**/*.bak"
  ]
}

在这个配置中，exclude 配置项不仅排除了 node_modules 目录下的所有文件，还排除了 logs 目录下的所有文件以及所有扩展名为 .log 或 .bak 的文件。

总之，exclude 配置项在 tsconfig.json 中扮演着一个重要的角色，它允许你精确地控制哪些文件应该被 TypeScript 编译器忽略。

注意：exclude 配置项是基于 include 配置项所指定的路径去查找需要排除的文件。换句话说，exclude 会从 include 所包含的文件或文件夹中排除指定的文件或文件夹。

include 配置项用于指定哪些文件或文件夹应该被 TypeScript 编译器编译，而 exclude 配置项则用于从 include 所指定的范围中排除某些文件或文件夹。这意味着，如果某个文件或文件夹同时出现在 include 和 exclude 中，那么它最终会被 exclude 所排除，不会被编译。

例如，假设你有以下的 tsconfig.json 配置：

{
  "include": ["src/**/*"],
  "exclude": ["src/test/*", "src/params/*"]
}

在这个例子中，include 指定了 src 目录下的所有文件都应该被编译。然后，exclude 指定了 src/test/* 和 src/params/* 这两个文件夹下的所有文件都应该被排除。因此，最终只有 src 目录下除了 test 和 params 文件夹之外的其他文件会被编译。

总结来说，exclude 是基于 include 所指定的路径去查找和排除文件的，它确保了你不会编译那些不需要的文件，从而可以更加精确地控制编译过程。

4. files：指定编译文件列表

files 配置项用于明确指定要编译的 TypeScript 文件列表。

当你设置了 files 属性时，TypeScript 编译器只会编译这个列表中明确列出的文件，而不会编译项目中的其他文件，即使它们符合 include 或 exclude 规则。

使用 files 的一个典型场景是当你想要明确地控制哪些文件被编译，而不是依赖于自动的文件匹配规则（比如 include 和 exclude）。这在你想要排除某些文件或确保只有特定文件被编译时非常有用。

这里是一个简单的 tsconfig.json 示例，展示了如何使用 files 配置项：

{
  "compilerOptions": {
    // 编译器选项...
  },
  "include": [
    // 通常情况下，你会包含一些目录或文件模式
    "src/**/*"
  ],
  "exclude": [
    // 排除某些文件或目录
    "node_modules"
  ],
  "files": [
    // 明确指定要编译的文件列表
    "src/index.ts",
    "src/utils/helper.ts"
  ]
}

在这个示例中，尽管 include 配置项指定了包含 src 目录下的所有文件，但 files 配置项覆盖了这一行为，并明确指定了只编译 src/index.ts 和 src/utils/helper.ts 这两个文件。这意味着，即使 src 目录下有其他 .ts 文件，它们也不会被编译。

需要注意的是，如果 files 和 include 同时存在，files 会覆盖 include。同样，如果 files 和 exclude 同时存在，files 也会覆盖 exclude。因此，当使用 files 时，你需要确保列表中包含了你想要编译的所有文件，并且没有遗漏。

5. extends：继承配置

extends 配置项用于指定一个或多个基础配置文件，从而允许你在多个项目或配置之间共享 TypeScript 编译器的配置。

使用 extends 配置项可以在一个 tsconfig.json 文件中引用另一个 tsconfig.json 文件。被引用的文件通常包含一组共享的、基础的编译器设置，而当前的 tsconfig.json 文件则可以在此基础上添加或覆盖特定于当前项目的设置。

举一个简单的例子，展示如何使用 extends 配置项：

// 在项目的根目录下有一个基础的 tsconfig.base.json
{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "strict": true,
    // 其他共享的配置...
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

// 在一个子项目的根目录下有一个 tsconfig.json，它扩展了基础配置
{
  "extends": "../tsconfig.base.json",
  "compilerOptions": {
    "outDir": "dist/subproject",
    // 特定于此项目的配置...
  },
  "include": ["src/subproject"],
  // exclude 可以继承自基础配置，也可以在这里重写
}

该例中，tsconfig.json 在子项目中引用了位于项目根目录的 tsconfig.base.json 文件。这意味着子项目的编译配置将继承基础配置中的所有设置，但也可以添加或覆盖特定的设置。在这个例子中，子项目指定了一个不同的 outDir，这是特定于该项目的输出目录。

6. references：跨项目引用类型

references 配置项在 tsconfig.json 文件中是 TypeScript 3.0 引入的一个功能，它允许你将一个大型的 TypeScript 项目拆分成多个小的、独立的项目或库，并且这些项目或库之间可以相互引用和依赖。通过 references 配置项，你可以指定项目之间的依赖关系，确保在编译时能够正确地处理这些依赖。

references 配置项是一个数组，其中每个元素都是一个对象，表示一个依赖项目。每个对象至少需要包含一个 path 属性，该属性指定了依赖项目的相对路径或绝对路径。

使用 references 配置项的好处包括：

类型安全：确保引用的项目提供了正确的类型定义，从而在编译时捕获类型错误。
构建优化：允许编译器在构建过程中只编译必要的文件，提高构建效率。
项目结构清晰：通过将大型项目拆分成多个小的项目或库，可以使项目结构更加清晰和可维护。

需要注意的是，references 配置项并不会自动安装或链接依赖项目。你仍然需要手动管理这些依赖项目的安装和版本控制。此外，被引用的项目（如 projectA）也需要是一个合法的 TypeScript 项目，具有自己的 tsconfig.json 文件和正确的编译配置。

5.1. references使用示例

例如，假设你有两个 TypeScript 项目：projectA 和 projectB。projectB 依赖于 projectA 中定义的一些类型和函数。

以下是如何使用 ProjectA 中的类型的步骤：

设置 ProjectA：

- 首先，确保 ProjectA 是一个独立的 TypeScript 项目，并且有自己的 tsconfig.json 文件。
- 在 ProjectA 的 tsconfig.json 文件中，确保你已经定义了要导出的类型。这通常是通过设置 "declaration": true 来完成的，这会生成 .d.ts 文件，其中包含你的类型定义。

在引用项目中设置：

- 在你的主项目中（假设为 ProjectB），你也需要有一个 tsconfig.json 文件。
- 在 ProjectB 的 tsconfig.json 文件中，使用 "references" 配置项来引用 ProjectA。例如：

{
  "compilerOptions": {
    // 其他编译器选项...
  },
  "include": [
    "src/**/*"
  ],
  "references": [
    {
      "path": "../projectA"
    }
  ]
}

使用类型：

- 在 ProjectB 中，你现在可以直接导入和使用 ProjectA 中定义的类型。例如，如果 ProjectA 中有一个名为 MyType 的类型，你可以在 ProjectB 中这样使用它：

import { MyType } from 'projectA';

const myVariable: MyType = ...;

注意，这里的 'projectA' 是你在 ProjectA 的 package.json 文件中定义的名称。

编译：

- 当你编译 ProjectB 时，TypeScript 编译器会自动处理项目引用，并确保正确地解析和使用 ProjectA 中的类型。

{
  "compilerOptions": {
    // 其他编译器选项...
  },
  "include": [
    "src/**/*"
  ],
  "references": [
    {
      "path": "../projectA"
    }
  ]
}

这里，"path" 应该是相对于当前 tsconfig.json 文件的 ProjectA 的路径。

import { MyType } from 'projectA';

const myVariable: MyType = ...;

注意，这里的 'projectA' 是你在 ProjectA 的 package.json 文件中定义的名称。

通过使用项目引用，你可以轻松地在多个 TypeScript 项目之间共享类型和其他代码，同时保持项目的独立性和可维护性。

初始化tsconfig.json文件

生成tsconfig.json文件

# 项目根目录下执行命令
npx tsc --init

生成的初始文件，不同Typescript版本生成的初始文件有一些细微差异，以下以5.4.2版本json文件为例：

{
  "compilerOptions": {
    /* Visit https://aka.ms/tsconfig to read more about this file */

    /* Projects */
    // "incremental": true,                              /* Save .tsbuildinfo files to allow for incremental compilation of projects. */
    // "composite": true,                                /* Enable constraints that allow a TypeScript project to be used with project references. */
    // "tsBuildInfoFile": "./.tsbuildinfo",              /* Specify the path to .tsbuildinfo incremental compilation file. */
    // "disableSourceOfProjectReferenceRedirect": true,  /* Disable preferring source files instead of declaration files when referencing composite projects. */
    // "disableSolutionSearching": true,                 /* Opt a project out of multi-project reference checking when editing. */
    // "disableReferencedProjectLoad": true,             /* Reduce the number of projects loaded automatically by TypeScript. */

    /* Language and Environment */
    "target": "es2016",                                  /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */
    // "lib": [],                                        /* Specify a set of bundled library declaration files that describe the target runtime environment. */
    // "jsx": "preserve",                                /* Specify what JSX code is generated. */
    // "experimentalDecorators": true,                   /* Enable experimental support for legacy experimental decorators. */
    // "emitDecoratorMetadata": true,                    /* Emit design-type metadata for decorated declarations in source files. */
    // "jsxFactory": "",                                 /* Specify the JSX factory function used when targeting React JSX emit, e.g. 'React.createElement' or 'h'. */
    // "jsxFragmentFactory": "",                         /* Specify the JSX Fragment reference used for fragments when targeting React JSX emit e.g. 'React.Fragment' or 'Fragment'. */
    // "jsxImportSource": "",                            /* Specify module specifier used to import the JSX factory functions when using 'jsx: react-jsx*'. */
    // "reactNamespace": "",                             /* Specify the object invoked for 'createElement'. This only applies when targeting 'react' JSX emit. */
    // "noLib": true,                                    /* Disable including any library files, including the default lib.d.ts. */
    // "useDefineForClassFields": true,                  /* Emit ECMAScript-standard-compliant class fields. */
    // "moduleDetection": "auto",                        /* Control what method is used to detect module-format JS files. */

    /* Modules */
    "module": "commonjs",                                /* Specify what module code is generated. */
    // "rootDir": "./",                                  /* Specify the root folder within your source files. */
    // "moduleResolution": "node10",                     /* Specify how TypeScript looks up a file from a given module specifier. */
    // "baseUrl": "./",                                  /* Specify the base directory to resolve non-relative module names. */
    // "paths": {},                                      /* Specify a set of entries that re-map imports to additional lookup locations. */
    // "rootDirs": [],                                   /* Allow multiple folders to be treated as one when resolving modules. */
    // "typeRoots": [],                                  /* Specify multiple folders that act like './node_modules/@types'. */
    // "types": [],                                      /* Specify type package names to be included without being referenced in a source file. */
    // "allowUmdGlobalAccess": true,                     /* Allow accessing UMD globals from modules. */
    // "moduleSuffixes": [],                             /* List of file name suffixes to search when resolving a module. */
    // "allowImportingTsExtensions": true,               /* Allow imports to include TypeScript file extensions. Requires '--moduleResolution bundler' and either '--noEmit' or '--emitDeclarationOnly' to be set. */
    // "resolvePackageJsonExports": true,                /* Use the package.json 'exports' field when resolving package imports. */
    // "resolvePackageJsonImports": true,                /* Use the package.json 'imports' field when resolving imports. */
    // "customConditions": [],                           /* Conditions to set in addition to the resolver-specific defaults when resolving imports. */
    // "resolveJsonModule": true,                        /* Enable importing .json files. */
    // "allowArbitraryExtensions": true,                 /* Enable importing files with any extension, provided a declaration file is present. */
    // "noResolve": true,                                /* Disallow 'import's, 'require's or '<reference>'s from expanding the number of files TypeScript should add to a project. */

    /* JavaScript Support */
    // "allowJs": true,                                  /* Allow JavaScript files to be a part of your program. Use the 'checkJS' option to get errors from these files. */
    // "checkJs": true,                                  /* Enable error reporting in type-checked JavaScript files. */
    // "maxNodeModuleJsDepth": 1,                        /* Specify the maximum folder depth used for checking JavaScript files from 'node_modules'. Only applicable with 'allowJs'. */

    /* Emit */
    // "declaration": true,                              /* Generate .d.ts files from TypeScript and JavaScript files in your project. */
    // "declarationMap": true,                           /* Create sourcemaps for d.ts files. */
    // "emitDeclarationOnly": true,                      /* Only output d.ts files and not JavaScript files. */
    // "sourceMap": true,                                /* Create source map files for emitted JavaScript files. */
    // "inlineSourceMap": true,                          /* Include sourcemap files inside the emitted JavaScript. */
    // "outFile": "./",                                  /* Specify a file that bundles all outputs into one JavaScript file. If 'declaration' is true, also designates a file that bundles all .d.ts output. */
    // "outDir": "./",                                   /* Specify an output folder for all emitted files. */
    // "removeComments": true,                           /* Disable emitting comments. */
    // "noEmit": true,                                   /* Disable emitting files from a compilation. */
    // "importHelpers": true,                            /* Allow importing helper functions from tslib once per project, instead of including them per-file. */
    // "importsNotUsedAsValues": "remove",               /* Specify emit/checking behavior for imports that are only used for types. */
    // "downlevelIteration": true,                       /* Emit more compliant, but verbose and less performant JavaScript for iteration. */
    // "sourceRoot": "",                                 /* Specify the root path for debuggers to find the reference source code. */
    // "mapRoot": "",                                    /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSources": true,                            /* Include source code in the sourcemaps inside the emitted JavaScript. */
    // "emitBOM": true,                                  /* Emit a UTF-8 Byte Order Mark (BOM) in the beginning of output files. */
    // "newLine": "crlf",                                /* Set the newline character for emitting files. */
    // "stripInternal": true,                            /* Disable emitting declarations that have '@internal' in their JSDoc comments. */
    // "noEmitHelpers": true,                            /* Disable generating custom helper functions like '__extends' in compiled output. */
    // "noEmitOnError": true,                            /* Disable emitting files if any type checking errors are reported. */
    // "preserveConstEnums": true,                       /* Disable erasing 'const enum' declarations in generated code. */
    // "declarationDir": "./",                           /* Specify the output directory for generated declaration files. */
    // "preserveValueImports": true,                     /* Preserve unused imported values in the JavaScript output that would otherwise be removed. */

    /* Interop Constraints */
    // "isolatedModules": true,                          /* Ensure that each file can be safely transpiled without relying on other imports. */
    // "verbatimModuleSyntax": true,                     /* Do not transform or elide any imports or exports not marked as type-only, ensuring they are written in the output file's format based on the 'module' setting. */
    // "allowSyntheticDefaultImports": true,             /* Allow 'import x from y' when a module doesn't have a default export. */
    "esModuleInterop": true,                             /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables 'allowSyntheticDefaultImports' for type compatibility. */
    // "preserveSymlinks": true,                         /* Disable resolving symlinks to their realpath. This correlates to the same flag in node. */
    "forceConsistentCasingInFileNames": true,            /* Ensure that casing is correct in imports. */

    /* Type Checking */
    "strict": true,                                      /* Enable all strict type-checking options. */
    // "noImplicitAny": true,                            /* Enable error reporting for expressions and declarations with an implied 'any' type. */
    // "strictNullChecks": true,                         /* When type checking, take into account 'null' and 'undefined'. */
    // "strictFunctionTypes": true,                      /* When assigning functions, check to ensure parameters and the return values are subtype-compatible. */
    // "strictBindCallApply": true,                      /* Check that the arguments for 'bind', 'call', and 'apply' methods match the original function. */
    // "strictPropertyInitialization": true,             /* Check for class properties that are declared but not set in the constructor. */
    // "noImplicitThis": true,                           /* Enable error reporting when 'this' is given the type 'any'. */
    // "useUnknownInCatchVariables": true,               /* Default catch clause variables as 'unknown' instead of 'any'. */
    // "alwaysStrict": true,                             /* Ensure 'use strict' is always emitted. */
    // "noUnusedLocals": true,                           /* Enable error reporting when local variables aren't read. */
    // "noUnusedParameters": true,                       /* Raise an error when a function parameter isn't read. */
    // "exactOptionalPropertyTypes": true,               /* Interpret optional property types as written, rather than adding 'undefined'. */
    // "noImplicitReturns": true,                        /* Enable error reporting for codepaths that do not explicitly return in a function. */
    // "noFallthroughCasesInSwitch": true,               /* Enable error reporting for fallthrough cases in switch statements. */
    // "noUncheckedIndexedAccess": true,                 /* Add 'undefined' to a type when accessed using an index. */
    // "noImplicitOverride": true,                       /* Ensure overriding members in derived classes are marked with an override modifier. */
    // "noPropertyAccessFromIndexSignature": true,       /* Enforces using indexed accessors for keys declared using an indexed type. */
    // "allowUnusedLabels": true,                        /* Disable error reporting for unused labels. */
    // "allowUnreachableCode": true,                     /* Disable error reporting for unreachable code. */

    /* Completeness */
    // "skipDefaultLibCheck": true,                      /* Skip type checking .d.ts files that are included with TypeScript. */
    "skipLibCheck": true                                 /* Skip type checking all .d.ts files. */
  }
}

Typescript: tsconfig.json文件常见配置项剖析

1. compilerOptions - 编译配置

1.1. Projects 项目配置

1.1.1. incremental：增量编译

1.1.2. composite：复合项目

1.1.3. tsBuildInfoFile: 增量编译信息文件路径

1.1.4. disableSourceOfProjectReferenceRedirect: 是否禁用项目引用源的重定向

1.1.5. disableSolutionSearching：是否搜索解决方案（.sln）文件来自动添加项目引用

1.1.6. disableReferencedProjectLoad：是否加载引用

1.2. Language and Environment 语言和环境

1.2.1. target：编译目标版本

1.2.2. lib：标准库

1.2.3. jsx：编译jsx语法

1.2.4. experimentalDecorators：是否启用装饰器

1.2.5. noLib：是否包含默认库文件

1.2.6. TODO=====>待补充

1.3. Modules

1.3.1. module： 编译后代码的模块系统

1.3.2. rootDir：指定 TypeScript 源代码的根目录

1.3.3. moduleResolution：模块解析方式

1.3.4. baseUrl：解析非相对模块名称的基准目录

1.3.4.1. baseUrl与rootDir的区别

1.3.4.2. baseUrl与rootDir的作用

1.3.5. paths：定义路径别名

1.3.6. rootDirs：设置同一虚拟目录

1.3.7. typeRoots：指定声明文件搜索路径

1.3.8. types：指定需要包含的类型声明文件

1.3.8.1. typeRoots和types的区别

1.3.8.2. typeRoots和types的作用

1.3.8.2.1. typeRoots

1.3.8.2.2. types

1.3.9. TODO=====>待补充

1.4. JavaScript Support

1.4.1. allowJs：允许编译Javascript文件

1.4.2. checkJs：允许检查Javascript文件

1.4.3. maxNodeModuleJsDepth

1.5. Emit

1.5.1. declaration：是否生成声明文件

1.5.2. declarationMap：源代码映射

1.5.3. declarationDir：指定生成的声明文件目录

1.5.4. outFile：输出文件的合并路径

1.5.5. outDir：输出文件的目录

1.5.5.1. outFile与outDir的区别

1.5.5.2. outFile与outDir的作用

1.5.6. TODO=====>待补充

1.6. Interop Constraints

1.7. Type Checking

1.7.1. strict：开启严格检查模式

1.8. Completeness

1.8.1. skipDefaultLibCheck：跳过默认库检测

1.8.2. skipLibCheck：跳过所有声明文件（.d.ts 文件）的类型检查

2. include：指定编译文件或文件夹

3. exclude: 指定排除在编译过程外文件或者文件夹

4. files：指定编译文件列表

5. extends：继承配置

6. references：跨项目引用类型

5.1. references使用示例

初始化tsconfig.json文件

1.3.1. module：编译后代码的模块系统