tsconfig.json编译选项配置说明_tsconfig.node.json

• incremental 增量编译，默认在 composite为true的为true，否则false

语言和环境

• target : 编译目标,默认 es3
• reactNamespace; react的命名空间，默认React
• lib： TypeScript 包括一组默认的内置 JS API（如Math）类型定义，以及浏览器环境中的类型定义（如document）。TypeScript 还包括用于匹配target您指定的较新 JS 功能的 API ；例如，Map如果target是ES6或更新，则定义可用。官方
• noLib： 禁用自动包含任何库文件。默认为false 。 当启用这个设置的时候，Array, Boolean, Function, IArguments, Number, Object, RegExp, 和String等类型都需要自己定义。
• jsx: 默认react , 控制如何在 JavaScript 文件中发出 JSX 构造。这只会影响文件中开始的 JS 文件的输出.tsx。
• experimentalDecorators : 启用对装饰器的支持
• emitDecoratorMetadata： 为装饰器输出类型支持

模块

输出

类型检查

交互约束

• esModuleInterop （默认false）

• allowSyntheticDefaultImports
  如果module===‘system’，或开启esModuleInterop并且module不是es6/es2015/esnext 的时候为true, 否则为false。

  typescript编译选项esModuleInterop的作用

• forceConsistentCasingInFileNames（默认 false）
  强制文件名区分大小写

• isolatedModules（默认 false）
  将每个文件作为单独的模块，当启用的时候，所有实现文件都必须是模块（这意味着它具有某种形式的import/ export）
  限制不适用于.d.ts文件

• preserveSymlinks

Javascript 支持

编辑器支持

reference

项目引用是 TypeScript 3.0的新特性，它支持将 TypeScript 程序的结构分割成更小的组成部分。

这是 typescript 官网中的描述，那怎么理解这句话呢。我们通过一个场景认识新出这种的 reference 特性。

假设我们要开发一个类似于 lodash 的工具库，并在项目中使用，而且后期很有可能还要在业界推广。为了保证这个工具的顺利开发及推广，我们必须要做相应的单元测试。那这个工具库可以看做一个项目，对其中的每个功能的测试也可作为一个独立的项目。但整个过程中，工具库的开发和测试应该是属于同一个项目下 “分项目” 的。那这种情况下 reference 就很棒了。首先我们搭一个目录出来：

|---- src/
 |---- index.ts // 整个工具库的入口
 |---- copyDeep.ts // 其中定义了copyDeep方法
|---- test/
 |---- copyDeep.test.ts // copyDeep的单元测试
|---- package.json
|---- tsconfig.json
1
2
3
4
5
6
7

在 copyDeep.test.ts 中肯定要引用 src/copyDeep，也就是说 test 的项目是依赖于 src 的。如果 src 中的代码发生了变化，整个工具库项目应该重新编译，而 test 项目不应该再被编译，这本来就是合理的。如果 test 项目中的代码发生了变化，那 test 项目应该被重新编译，而 src 项目不应该再被编译。如何在一个项目中配置而做到分别编译相应的子项目呢？首先最先想到的应该是在 tsconfig.json 文件中引入 include 字段配置，我们先尝试一下下面的配置：

{
 "files": [
 "./src/index.ts"
 ],
 "include": [
 "./test/**/*.test.ts"
 ],
 "compilerOptions": {
 "outDir": "./dist/"
 }
}
1
2
3
4
5
6
7
8
9
10
11

我们来分析这样配置的会有哪些问题：

1. 首先，从整个项目层面，确实做到了修改任意文件重新编译的功能。但注意，编译的是全量的 ts 文件。
2. 随着日后项目的增大，在 *.test.ts 文件中引入也将逐渐变大。
3. 修改了 src//**/*.ts 的内容，test/**/*.ts 也将作为输出，这是我们不希望看到的。

此时，reference 将解决上述的每一个问题，我们修改项目结构如下：

|---- src/
 |---- index.ts // 整个工具库的入口
 |---- copyDeep.ts // 其中定义了copyDeep方法
 |---- tsconfig.json // 工具库的编译配置文件
|---- test/
 |---- copyDeep.test.ts // copyDeep的单元测试
 |---- tsconfig.json // 测试的编译配置文件
|---- package.json
|---- tsconfig.json
1
2
3
4
5
6
7
8
9

并修改为以下配置：

// 根目录下的 /tsconfig.json
{
 "compilerOptions": {
 "declaration": true, // 为子项目生成.d.ts声明文件
 "outDir": "./dist",
 }
}

// src目录下的 /src/tsconfig.json
{
 "extends": "../tsconfig",
 "compilerOptions": {
 "composite": true // 必须设置为true，表明该文件夹为一个子项目
 }
}

// test目录下的 /src/tsconfig.json
{
 "extends": "../tsconfig",
 "references": [
 { "path": "../src" } // 表示引用了工具库项目
 ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

这样配置后，如果 src 项目已经编译完成并且输出了编译后的文件， 那在 test 项目中，实际加载的是 src 项目声明的 .d.ts 文件，而且这个声明文件是对 test 项目可见的。另外，如果开启了 watch 模式，修改了内容只会编译相应的项目而不会全量编译。这会显著的加速类型检查和编译，减少编辑器的内存占用。而且在代码结构层命有了一个很清晰的规划。

总结来讲，refrence 的作用是将两个项目关联起来作为一个项目开发，当某个项目代码修改后还能单独编译相应的项目而不是整个项目。再说的简单点，就是实现了关联项目间的懒编译。