积极让人记住的tsconfig.json配置先容

详解 compilerOptions 配置

compilerOptions.target

类型: "es3" | "es5" | "es6" | "es2015" | "es2016" | "es2017" | "es2018" | "es2019" | "es2020" | "es2021" | "es2022" | "es2023" | "esnext"
默认值: "es3"
作用: 指定生成代码的 ECMAScript 版本。
使用场景: 根据运行情况选择符合的 ECMAScript 版本，以使用最新的语言特性。
compilerOptions.jsx

类型: "preserve" | "react" | "react-jsx" | "react-jsxdev" | "react-native"
默认值: "preserve"
作用: 指定 JSX 的编译模式。"preserve" 保留 JSX 以供其他工具处置惩罚，"react" 编译为 React.createElement 调用，"react-jsx" 和 "react-jsxdev" 针对 React 17 及以后。
使用场景: 用于 React 项目中，以控制 JSX 如何被编译。
compilerOptions.experimentalDecorators

类型: boolean
默认值: false
作用: 启用实验性的 ES 装饰器特性。
使用场景: 在使用装饰器（如在 Angular、NestJS 等框架中）时须要启用。
compilerOptions.emitDecoratorMetadata

类型: boolean
默认值: false
作用: 在编译输出中生成装饰器元数据。该选项用于配合装饰器（Decorators）使用，为类型和类成员生成元数据。
使用场景:当你使用 TypeScript 的装饰器功能，并且须要访问类型和参数的元数据时（例如，使用依赖注入框架或一些 ORM 库），启用此选项。
compilerOptions.jsxFactory

类型: string
默认值: React.createElement
作用: 指定在 JSX 编译时使用的工厂函数。一样平常与 jsx 选项一起使用。
使用场景: 使用非标准的 JSX 工厂时须要指定，比如使用 h 作为 JSX 工厂时。
compilerOptions.jsxFragmentFactory

类型: string
默认值: React.Fragment
作用: 指定在编译 JSX 片段时使用的工厂函数。
使用场景: 当你须要使用非标准的 JSX 片段处置惩罚时。
compilerOptions.jsxImportSource

类型: string
默认值: undefined
作用: 当 jsx 选项为 "react-jsx" 或 "react-jsxdev" 时，指定用于导入 JSX 工厂函数和片段的模块。
使用场景: 与新的 React JSX 转换模式一起使用，指定自定义的 JSX 工厂来源。
compilerOptions.noLib

类型: boolean
默认值: false <br>**作用**: 不包含默认的库文件（如lib.d.ts`）。
使用场景: 自定义情况或不须要标准库时使用。
compilerOptions.module

类型: "none" | "commonjs" | "amd" | "system" | "umd" | "esnext" | "es6" | "es2015" | "node16" | "nodenext"
默认值: 取决于 target，通常为 commonjs
作用: 指定生成代码时使用的模块系统。
使用场景: 根据运行情况（如 Node.js、欣赏器等）或项目需求选择符合的模块系统。
compilerOptions.rootDir

类型: string
默认值: 计算出来的公共路径
作用: 指定编译器用于输出文件路径计算的根目次。影响编译输出目次结构。
使用场景: 当你须要控制源文件目次与输出文件目次的映射关系时使用。
rootDir 选项用于定义项目中源代码文件的起始位置（根目次），TypeScript 编译器会以这个目次作为基准来处置惩罚文件，并保持文件结构一致性。当编译器将 TypeScript 文件转换为 JavaScript 文件时，rootDir 决定了输入文件的相对路径，从而影响最终输出的目次结构。

1. project/
2. ├── src/
3. │   ├── utils/
4. │   │   └── helper.ts
5. │   ├── components/
6. │   │   └── header.ts
7. │   └── main.ts
8. └── tsconfig.json

复制代码

在 tsconfig.json 中，rootDir 被指定为 src

1. {
2.   "compilerOptions": {
3.     "rootDir": "./src",
4.     "outDir": "./dist"
5.   }
6. }

复制代码

这里 rootDir: "./src" 表示 TypeScript 编译器会把 src 目次下的全部文件当作编译输入的起始点。编译后，TypeScript 会将每个文件放入到 outDir 指定的输出目次中，并保留 rootDir 下的文件结构。

1. project/
2. ├── dist/
3. │   ├── utils/
4. │   │   └── helper.js
5. │   ├── components/
6. │   │   └── header.js
7. │   └── main.js
8. └── tsconfig.json

复制代码

可以看到，dist 目次中的文件结构与 src 目次中的结构是一致的。rootDir 确保了这个一致性，编译器根据 src 目次下文件的相对路径，将它们放在 dist 目次下的相应位置。
compilerOptions.moduleResolution

类型: "node" | "classic"
默认值: node
作用: 指定模块分析策略，node 模式模仿 Node.js 的分析机制，classic 模式是 TypeScript 的旧分析方式。
使用场景: 根据项目需求选择模块分析策略，当代项目通常使用 node 模式。
compilerOptions.baseUrl

类型: string
默认值: ./
作用: 用于分析非相对模块导入的基准路径。
使用场景: 当你使用非相对路径导入模块时（如 import x from "module"），TypeScript 将从 baseUrl 开始分析。
baseUrl 是用来指定模块分析时的基准路径。当你在 Typescript 代码中使用非相对路径（即不以 ./ 或 ../ 开头的路径）导入模块时，Typescript 编译器会从 baseUrl 开始查找这个模块。
假设项目结构如下：

1. project/
2. ├── src/
3. │   ├── utils/
4. │   │   └── helpers.ts
5. │   ├── components/
6. │   │   └── header.ts
7. │   └── main.ts
8. └── tsconfig.json

复制代码

如果在 tsconfig.json 中配置 baseUrl 为 src

1. {
2.   "compilerOptions": {
3.     "baseUrl": "./src"
4.   }
5. }

复制代码

在这种情况下，你可以在 main.ts 中这样导入 helpers.ts：

1. import { helperFunction } from "utils/helpers";

复制代码

这里的 'utils/helpers' 是相对于 baseUrl (./src) 的路径。TypeScript 编译器会从 src 目次开始查找 utils/helpers.ts 文件。
compilerOptions.rootDirs

类型: string[]
默认值: []（空数组）
作用: rootDirs 允许你指定一个或多个目次，这些目次中的文件可以作为一个团体来处置惩罚。这对于构造多个源文件目次，尤其是在大型项目中，特殊有用。 当使用 rootDirs 时，TypeScript 编译器将把这些目次视为一个逻辑根目次，以便在生成输出文件时可以或许保持相对路径结构。

使用场景

• 代码分割: 当你的项目文件结构分散在多个目次中，但盼望它们在编译时体现为一个单一的逻辑结构时，rootDirs 非常有用。例如，一个项目可能在 src 和 lib 目次中都有源代码，通过设置 rootDirs，可以将这些目次视为同一根目次。
  
• 制止路径题目: 当在多个目次中有相同名称的文件时，rootDirs 可以帮助 TypeScript 处置惩罚这些文件，确保在编译时正确引用它们，而不会引发路径冲突。
  
• 代码重用和共享: 如果有多个项目共享相同的代码库，可以使用 rootDirs 指向这些共享代码的多个位置，从而使得编译器可以或许正确地处置惩罚这些共享代码。
  

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

1. /project
2.   ├── src/
3.   │    ├── main.ts
4.   │    └── utils/
5.   │         └── helper.ts
6.   ├── lib/
7.   │    └── shared.ts
8.   └── tsconfig.json

复制代码

在 tsconfig.json 中，你可以这样配置 rootDirs：

1. {
2.   "compilerOptions": {
3.     "rootDirs": ["src", "lib"]
4.   }
5. }

复制代码

在这个配置下，当你运行 TypeScript 编译时，输出的文件会生存在指定的 outDir 目次（这里是 dist），并保持原有目次结构。输出的文件结构将会是：

1. /project
2.   ├── dist/
3.   │    ├── main.js
4.   │    ├── utils/
5.   │    │    └── helper.js
6.   │    └── shared.js
7.   ├── src/
8.   ├── lib/
9.   └── tsconfig.json

复制代码

通过使用 rootDirs，你可以将多个目次作为逻辑上的根目次，这样在输出编译后的文件时，可以或许保持原有的目次结构，制止了路径冲突，并使得项目结构更加灵活和清晰。输出的目次结构将与逻辑根目次中的文件相对路径一致。
compilerOptions.typeRoots

类型: string[]
默认值: ["node_modules/@types"]
作用: typeRoots 用于指定一个或多个目次，TypeScript 将在这些目次中查找类型声明文件（.d.ts 文件）。这通常用于定义自定义的类型库或指定特定位置的类型定义。 默认情况下，TypeScript 会在 node_modules/@types 目次中查找类型定义，但你可以通过 typeRoots 指定其他目次。

使用场景: 当你有自定义的类型定义文件存放在特定目次时，可以使用 typeRoots 指定这些目次。 在大型项目中，如果你盼望将第三方库的类型定义和项目自定义类型定义分开，可以通过设置多个 typeRoots 来实现。
示例:

1. {
2.   "compilerOptions": {
3.     "typeRoots": ["./types", "./custom-types"]
4.   }
5. }

复制代码

在这个示例中，TypeScript 将会在 ./types 和 ./custom-types 目次中查找类型定义文件。
compilerOptions.types

类型: string[]
默认值: []（空数组，表示包含全部类型）
作用: types 用于明确指定 TypeScript 在编译时须要包含的类型声明包。它允许你选择性地引入某些类型，而不是默认包含全部在 typeRoots 指定目次下的类型。 通过使用 types，你可以控制哪些类型声明文件被包含在编译过程中。

使用场景: 当你只想要某些特定的类型库时，例如只使用 @types/lodash 和 @types/jest，而不盼望 TypeScript 默认加载其他类型库。 有助于淘汰编译时间和内存使用，特殊是在大型项目中。
示例:

1. {
2.   "compilerOptions": {
3.     "types": ["lodash", "jest"]
4.   }
5. }

复制代码

在这个示例中，TypeScript 只会加载 lodash 和 jest 的类型声明，而不会加载 node_modules/@types 下的全部其他类型声明。
compilerOptions.paths

类型: { [key: string]: string[] }
默认值: undefined
作用: 设置模块导入的路径映射。配合 baseUrl 使用，指定模块导入时的别名或路径更换。
使用场景: 配置路径别名，如将 @app 映射到 src/app，简化模块导入路径。
paths 允许你为模块设置路径别名或自定义路径映射，使得你可以使用简短或特定的路径来导入模块，而不用担心相对路径的层级题目。
paths 通常须要结合 baseUrl 一起使用。paths 的键表示导入模块的别名模式，值是一个数组，数组中的每一项表示现实对应的路径。
继承上面的项目结构，假设你盼望为 utils 目次和 components 目次创建简短的别名，可以这样配置 paths：

1. {
2.   "compilerOptions": {
3.     "baseUrl": "./src",
4.     "paths": {
5.       "@utils/*": ["utils/*"],
6.       "@components/*": ["components/*"]
7.     }
8.   }
9. }

复制代码

这样，你可以在 main.ts 中使用别名来导入模块：

1. import { helperFunction } from "@utils/helpers";
2. import { Header } from "@components/header";

复制代码

这里，@utils/* 对应的是 src/utils/*，@components/* 对应的是 src/components/*，其中 * 是通配符，表示匹配恣意名称。
baseUrl 和 paths 的关系 baseUrl 是底子路径：baseUrl 指定了非相对路径模块分析的出发点。全部通过非相对路径导入的模块都会先基于 baseUrl 进行分析。
paths 是路径映射规则：paths 在 baseUrl 的底子上，提供了更加灵活的路径映射和别名机制。它允许你为特定的路径创建别名，简化模块导入。

使用场景

• 简化导入路径 通过配置 baseUrl 和 paths，你可以制止在模块导入时使用复杂的相对路径，比如 ../../utils/helpers 这样的路径。取而代之，你可以使用更简洁和清晰的路径，比如 @utils/helpers。
  
• 模块重构更简单
  

如果项目中某个模块的位置发生了变化，只需修改 paths 配置，而不须要在整个项目中逐个修改导入路径。
总结 baseUrl：设定模块分析时的基准路径，使非相对路径的模块导入从指定目次开始查找。 paths：在 baseUrl 底子上提供路径别名或自定义路径映射，进一步简化和规范模块导入路径。
compilerOptions.noResolve

类型: boolean
默认值: false
作用: 当 noResolve 设置为 true 时，TypeScript 编译器将不会自动分析和导入未明确引用的模块。换句话说，编译器只会处置惩罚当前文件中显式引用的模块，而忽略其他文件中的模块和类型。 这意味着如果某个模块在文件中被引用但没有直接导入，编译器将不会思量该模块的类型信息。

使用场景

• 严格模式
  在某些情况下，开辟者可能盼望限制编译器的行为，以确保代码的严格性。设置 noResolve 为 true 可以确保只有显式导入的模块会被思量，这有助于发现和消除潜在的隐式依赖。
  
• 制止类型冲突
  在大型项目中，多个文件可能会相互依赖。使用 noResolve 可以防止因未显式导入的模块而引起的类型冲突或错误。这对于清晰地管理项目中的依赖关系非常有帮助。
  
• 快速编译 在一些情况下，开辟者可能盼望提高编译速率，尤其是在大型代码库中。通过禁用模块分析，可以淘汰编译器的工作量，从而提高编译性能。
  

示例
在 tsconfig.json 中启用 noResolve：

1. {
2.   "compilerOptions": {
3.     "noResolve": true
4.   }
5. }

复制代码

在这种配置下，如果你在某个文件中引用了一个未显式导入的模块，TypeScript 编译器将不会思量该模块的信息。例如：

1. // myModule.ts
2. export const myFunction = () => {
3.   return "Hello, world!";
4. };
6. // app.ts
7. console.log(myFunction()); // 这里会引发错误，因为 myFunction 未显式导入

复制代码

如果 noResolve 设置为 true，编译器将无法分析 myFunction，因为它没有在 app.ts 中被导入。
compilerOptions.allowJs

类型: boolean
默认值: false
作用: allowJs 用于指定 TypeScript 是否允许编译 .js 文件。默认情况下，TypeScript 只会编译 .ts 和 .tsx 文件。如果你盼望项目中同时包含 JavaScript 文件并让 TypeScript 处置惩罚这些文件，则须要将此选项设置为 true。 启用此选项后，TypeScript 会将 .js 文件纳入编译过程，允许你将现有的 JavaScript 代码逐步迁移到 TypeScript。

使用场景

• 渐进式迁移 当你有一个大型的 JavaScript 项目，并盼望逐步迁移到 TypeScript 时，启用 allowJs 可以使你在保留现有 JavaScript 代码的同时，引入 TypeScript 代码。
  
• 肴杂代码库 在一些项目中，可能须要同时使用 JavaScript 和 TypeScript 代码。此选项可以帮助你在一个项目中肴杂使用这两种语言。
  

示例
在 tsconfig.json 中启用 allowJs：

1. {
2.   "compilerOptions": {
3.     "allowJs": true
4.   }
5. }

复制代码

compilerOptions.checkJs

类型: boolean
默认值: false
作用: checkJs 用于控制 TypeScript 是否对 JavaScript 文件进行类型检查。当该选项设置为 true 时，TypeScript 将会对 .js 文件进行类型检查，报告类型错误。这使得 JavaScript 开辟者可以或许享受类型检查的好处，而不须要将全部文件转换为 TypeScript。 此选项通常与 allowJs 一起使用，以便在允许编译 JavaScript 文件的同时进行类型检查。

使用场景

• 提高代码质量 启用 checkJs 后，TypeScript 将检查 JavaScript 文件中的类型错误，帮助开辟者发现潜在的题目，从而提高代码的质量。
  
• 逐步迁移 在逐步将 JavaScript 代码迁移到 TypeScript 的过程中，启用 checkJs 可以帮助你在迁移过程中确保代码的正确性。
  

示例
在 tsconfig.json 中同时启用 allowJs 和 checkJs：

1. {
2.   "compilerOptions": {
3.     "allowJs": true,
4.     "checkJs": true
5.   }
6. }

复制代码

compilerOptions.maxNodeModuleJsDepth

类型: number
默认值: 0
作用: 指定从 node_modules 中分析 JavaScript 文件的最大深度。
使用场景: 控制编译器从 node_modules 中加载的文件深度，制止过深的依赖分析。
compilerOptions.declaration

类型: boolean
默认值: false
作用: 生成相应的 .d.ts 文件。
使用场景: 当你盼望发布一个 TypeScript 库并向外界提供类型声明文件时使用。
compilerOptions.declarationMap

类型: boolean
默认值: false
作用: 为 .d.ts 文件生成 source map 文件。
使用场景: 在调试声明文件时，可以映射回源文件。
compilerOptions.emitDeclarationOnly

类型: boolean
默认值: false
作用: 仅生成声明文件，而不生成 JavaScript 文件。
使用场景: 当你只须要生成类型声明文件（比如发布库时）。
compilerOptions.declarationDir

类型: string
默认值: 输出目次
作用: 指定生成的声明文件（.d.ts 文件）的输出目次。
使用场景: 分离声明文件与编译的 JavaScript 文件时使用。
compilerOptions.sourceMap

类型: boolean
默认值: false
作用: 为编译输出生成 .map 文件，便于调试代码时映射回源文件。
使用场景: 在调试编译后的 JavaScript 代码时使用，帮助开辟者定位题目。
compilerOptions.outFile

类型: string
默认值: undefined
作用: 将全部输出文件合并成一个文件，通常用于 AMD 或 System 模块。
使用场景: 当你须要将全部模块打包成一个文件进行部署时使用。
compilerOptions.removeComments

类型: boolean
默认值: false
作用: 在输出文件中删除全部解释。
使用场景: 当你盼望编译输出的文件更加精简时使用。
compilerOptions.noEmit

类型: boolean
默认值: false
作用: 不生成任何输出文件（包括 .js 和 .d.ts 文件）。
使用场景: 仅进行类型检查，而不须要生成编译输出时使用。
compilerOptions.newLine

类型: "crlf" | "lf"
默认值: 基于当前操纵系统
作用: 指定编译输出的换行符类型。
使用场景: 逼迫输出文件使用特定的换行符，比如在跨平台项目中保持一致性。
compilerOptions.noEmitOnError

类型: boolean
默认值: false
作用: 在编译错误时不生成输出文件。
使用场景: 包管在有编译错误时不会生成错误的编译输出。
compilerOptions.strict

类型: boolean
默认值: false
作用: 启用全部严格类型检查选项的总开关。
使用场景: 包管代码的类型安全性，制止常见的类型错误。
compilerOptions.alwaysStrict

类型: boolean
默认值: false
作用: 逼迫每个文件在编译输出时都以严格模式运行，相当于自动在文件顶部添加 "use strict";。
使用场景: 包管全部生成的 JavaScript 文件都以严格模式运行。
compilerOptions.strictNullChecks

类型: boolean
默认值: false
作用: 启用严格的空值检查，防止 null 和 undefined 被误用。
使用场景: 提高代码的可靠性，制止因 null 和 undefined 造成的错误。
compilerOptions.strictFunctionTypes

类型: boolean
默认值: false
作用: 启用对函数类型的严格检查，特殊是在处置惩罚协变和逆变的情况时。
使用场景: 强化函数的类型安全性，防止错误的函数类型赋值。
compilerOptions.strictBindCallApply

类型: boolean
默认值: false
作用: 启用对 bind、call 和 apply 方法的严格检查。
使用场景: 确保函数绑定和调用的参数类型是正确的。
compilerOptions.noImplicitAny

类型: boolean
默认值: false
作用: 克制隐式的 any 类型。对于没有显式类型注解的变量或参数，如果编译器无法推断类型，将会报错。
使用场景: 逼迫要求全部变量和函数参数都有明确的类型，淘汰类型错误。
compilerOptions.noImplicitThis

类型: boolean
默认值: false
作用: 克制 this 的隐式 any 类型，要求显式定义 this 的类型。
使用场景: 制止 this 在函数内部被错误使用，特殊是在回调函数中。
compilerOptions.noImplicitReturns

• 类型: boolean
  
• 
  默认值: false
  
• 
  作用: 确保函数中的每条代码路径都显式返回值，防止遗漏返回值的情况。
  
• 
  使用场景: 制止函数中有的路径没有返回值，导致运行时错误。
  

compilerOptions.noImplicitOverride

• 类型: boolean
  
• 
  默认值: false
  
• 
  作用: 要求子类中的方法必须使用 override 关键字显式标记覆盖父类的方法。
  
• 
  使用场景: 提拔代码的可读性和安全性，制止无意中覆盖父类方法。
  
• 
  

files、include、exclude 三者的关系和优先级

exclude、include 和 files 是 TypeScript 的 tsconfig.json 中用来控制哪些文件会被编译的三个配置选项。它们分别具有差别的作用和优先级，用来帮助开辟者精准地选择或清除文件。以下是对这三者关系的具体讲解。
files

files 明确指定要编译的文件列表。这个选项允许你列出一个确切的文件数组，只有这些文件会被 TypeScript 编译。
当你只想编译某些特定文件时，比如在一个大型项目中只编译部分文件进行测试或调试。
示例:

1. {
2.   "compilerOptions": { ... },
3.   "files": [
4.     "./src/index.ts",
5.     "./src/utils.ts"
6.   ]
7. }

复制代码

在这个示例中，只有 index.ts 和 utils.ts 会被编译，其他文件纵然在 include 中被提到或者存在于 exclude 外部，也不会被编译。
include

include 定义了一个模式数组，指定哪些文件或文件夹应该被编译。TypeScript 会根据这个模式匹配文件，并将其包括在编译过程中。
当须要须要对一组文件进行批量编译时，比如编译整个 src 目次下的全部 .ts 文件。
示例:

1. {
2.   "compilerOptions": { ... },
3.   "include": [
4.     "./src/**/*.ts"
5.   ]
6. }

复制代码

这个配置会编译 src 目次下的全部 TypeScript 文件，不论子目次层级如何。
exclude

exclude 定义了一个模式数组，指定哪些文件或文件夹应该被清除在编译之外。与 include 相反，exclude 是用来剔除不须要编译的文件的。
当某些文件夹中包含了不须要编译的文件时（例如测试文件夹，第三方库），可以使用 exclude 将它们清除。
示例

1. {
2.   "compilerOptions": { ... },
3.   "exclude": [
4.     "node_modules",
5.     "**/*.spec.ts"
6.   ]
7. }

复制代码

这个配置会清除全部 node_modules 目次中的文件以及全部测试文件（.spec.ts）。
三者之间的关系和优先级

• files 的优先级最高:
  
  
  
  • 如果你在 tsconfig.json 中设置了 files，那么 TypeScript 只会编译 files 中列出的文件，而忽略 include 和 exclude。纵然这些文件在 exclude 中被明确清除，它们仍然会被编译。
    
  
  
• include 和 exclude:
  
  
  
  • 如果没有 files 选项，TypeScript 会根据 include 和 exclude 来确定编译的文件。
    
  • include 决定哪些文件会被包括进来，而 exclude 则从 include 的结果中剔除掉一些文件。换句话说，TypeScript 先通过 include 选择文件，然后通过 exclude 过滤掉不须要编译的文件。
    
  
  
• 默认行为:
  
  
  
  • 如果既没有 files 也没有 include，那么 TypeScript 默认会编译 tsconfig.json 地点目次及其子目次中的全部 .ts、.tsx 和 .d.ts 文件，除了 node_modules、bower_components 和 jspm_packages 目次以及特定文件（如 tsconfig.json 中的 exclude 项指定的文件）。
    
  
  

示例总结

1. {
2.   "compilerOptions": { ... },
3.   "files": [
4.     "./src/index.ts"
5.   ],
6.   "include": [
7.     "./src/**/*.ts"
8.   ],
9.   "exclude": [
10.     "node_modules",
11.     "**/*.spec.ts"
12.   ]
13. }

复制代码

在这个示例中：

• 由于指定了 files，TypeScript 只会编译 src/index.ts，纵然 include 中的其他文件符合条件，也不会被编译。
  
• 如果删除 files，TypeScript 将会编译 src 目次下的全部 .ts 文件，除了 exclude 中列出的文件（例如 node_modules 和 .spec.ts 文件）。
  

总结

• files: 用于指定具体要编译的文件，优先级最高。
  
• include: 用于批量指定要编译的文件，优先级次于 files。
  
• exclude: 用于从 include 中清除不须要编译的文件，优先级最低。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。