Loading...
墨滴

DYBOY

2021/12/09  阅读:163  主题:自定义主题1

会写 TypeScript 但你真的会 TS 编译配置吗?

最近遇到了挺多涉及到前端“编译”方面的工作,其中关于 TypeScript 的编译会涉及到关于 tsconfig.json 文件的配置,由于配置项繁杂,遂逐一解析并验证,减少大家的一些疑惑,并提升工作效率!

随着 TypeScript 的流行,越来越多的项目通过使用 TypeScript 来实现编写代码时候的类型提示和约束,从开发过程中减少 BUG 出现的概率,以此提升程序的健壮性和团队的研发效率。

为什么会单独写一篇文章来讲述 tsconfig.json 文件的配置呐?原因是笔者在做 TS 项目的时候,由于对其中的配置项不熟悉,搞来搞去,搞好久,烦死了!所以决定好好梳理下。

越来越多的项目用上了 TypeScript,因此如何按需配置 tsconfig 也应该是前端工程师需要掌握的技能之一。

本文内容结构如下,朋友们按需食用🍚:

一、前置知识 💡

在熟悉掌握 tsconfig.json 文件配置前,先给首次接触 TS 的同学预备一下“前置知识”。

1.1 TypeScript 是什么?

TypeScript 官网:https://www.typescriptlang.org

TypeScript 是一种基于 JavaScript强类型编程语言,它使得在前端项目开发过程中更加严谨且流畅,一定程度上保证了大型前端项目程序的健壮性。

  • TypeScript 是由微软开发的一款开源的编程语言;
  • TypeScript 是 JavaScript 的超集,遵循最新的 ESM 规范,TypeScript 扩展了 JavaScript 的语法;
  • TypeScript 更像后端 JAVA、C# 这样的面向对象语言,可以让 JS 开发大型企业级项目。

但是 TypeScript 并不可以直接运行,而是需要转换成 JavaScript 代码才可以在 Node.js 或浏览器环境下执行,因此我们需要通过“编译器”将 TS 代码转换为 JS 代码。

1.2 什么是 tsc ?

tsc 的全称是 TypeScript Compiler,也就是将 TypeScript 转码为 JavaScript 代码的编译器。

tsc 的全局安装方式:

npm install typescript -g

当我们编译一份 index.ts 文件时,会使用下面的命令:

tsc ./index.ts

这样就可以得到一份编译成为 JavaScript 代码的 ./index.js 文件。

tsc 实际就是将 TS 转为 JS 的编译(器)脚手架工具,如果是一个 TS 的前端工程项目,那么就可以通过项目中的 tsconfig.json 文件来自定义配置 TS 编译相关规则。

项目中的 tsconfig.json 文件,我们一般会通过如下快捷命令生成:

tsc --init

执行完后,会在项目根目录生成一个简单的初始化 tsconfig.json 配置描述文件,如果没有特别的要求,该初始化配置就足以支持你愉快地使用 TS 开发啦!

更多相关 TS 编译配置和使用说明可以通过 tsc -h 查看。

1.3 tsconfig.json 文件

tsconfig.json[1] 文件是用于描述将 TypeScript 转为 JavaScript 代码的配置文件。

IDE(代码编辑器)将会根据 tsconfig.json 文件来对当前项目中支持不同程度的类型约束,同时也是对 TSC 编译 TypeScript 代码过程做一些预定义、约束入口和编译输出目录等配置。

因此对于一个支持 TypeScript 编程语言的工程来说,tsconfig.json 文件就是编码的基础。

二、tsconfig.json 配置详解 ⚙️

有了上面的前置知识作为基石,相信大家会对 tsconfig.json 文件的配置项也会更加容易理解。

tsconfig 协议
tsconfig 协议

笔者将从常见的配置项单独解释,然后在最后会将一些不常用的配置统一解释,朋友们可以将这篇文章收藏一下,可当作一份 tsconfig 配置的中文查询对照表 👀。

2.1 files

files 字段用于指明需要 tsc 编译的一个或多个 ts 文件,例如:

{
  "files": ["index.ts""global.d.ts"],
}

当指定的文件或文件夹不存在时,会提示 ❌ 错误!

2.2 include

include 字段用于指明需要被 tsc 编译的文件或文件夹列表,例如:

{
  "include": [
    "src",
    "global.d.ts"
  ],
}

2.3 exclude

exclude 字段用于排除不需要 tsc 编译的文件或文件夹列表,例如:

{
  "exclude": ["test.ts""src/test.ts"],
}

注意: exclude 字段中的声明只对 include 字段有排除效果,对 files 字段无影响,即与 include 字段中的值互斥。

如果 tsconfig.json 文件中 filesinclude 字段都不存在,则默认包含 tsconfig.json 文件所在目录及子目录的所有文件,且排除在 exclude 字段中声明的文件或文件夹。

2.4 compileOnSave

compileOnSave 是声明是否需要在保存时候自动触发 tsc 编译的字段,一般来说,我们的代码编译过程会通过 Rollup、Webpack 等打包构建工具,并且使用热更新,因此无需配置该项,保持缺省即可。

{
  "compileOnSave"false,
}

2.5 extends

extends 字段用于指明继承已有的 tsconfig 配置规则文件。

该字段可以说是非常有用了,因为我们的 tsconfig 配置其实各个项目之间大同小异,因此完全可以结合自己团队的情况,抽离一个基础且公共的 tsconfig 配置,并将其发包,然后作为 extends 字段的值来继承配置。

tsconfig 推荐默认配置可以参考官方的包:@tsconfig/recommended[2]

@tsconfig/recommended 的配置如下:

{
  "compilerOptions": {
    "target""ES2015",
    "module""commonjs",
    "strict"true,
    "esModuleInterop"true,
    "skipLibCheck"true,
    "forceConsistentCasingInFileNames"true
  },
  "$schema""https://json.schemastore.org/tsconfig",
  "display""Recommended"
}

例如继承一个发包后的 tsconfig 基础配置,并通过显示声明编译的目标代码版本为 ES2016 来覆盖覆盖 @tsconfig/recommended 中对应配置项。

{
  "extends""@tsconfig/recommended/tsconfig.json",
  "compilerOptions": {
    "target""ES2016"
  }
}

作为一些实践经验,社区也提供了一些常见环境(例如:Nuxt、Vite、Node 等)最佳实践后的基础配置,推荐参阅:https://github.com/tsconfig/bases/[3]

2.6 compilerOptions

compilerOptions 是一个描述 TypeScript 编译器功能的“大”字段,其值类型是“对象”,因此包含了很多用于描述编译器功能的子字段,其子字段的功能如下:

(1). target

target 字段指明经过 TSC 编译后的 ECMAScript 代码语法版本,根据 ECMAScript 语法标准,默认值为 ES3

TypeScript 是 JavaScript 的超集,是对 JavaScript 语法和类型上的扩展,因此我们可以使用 ES5、ES6,甚至是最新的 ESNext[4] 语法来编写 TS。例如当我们使用 ES2021 语法来编码 TS 文件,同时配置如下:

{
  "compilerOptions": {
    "target""ES5",
  }
}

则会将对应使用了最新 ECMAScript 语法的 TS 文件编译为符合 ES5 语法规范的 *.js 文件。

延伸一下知识点,思考一下 tsc 是如何将高版本(ECMAScript 规范)代码向低版本代码转换的?这个转换的结果靠谱吗?与 Babel 有何差异?

一图看 ECMAScript 各版本功能差异
一图看 ECMAScript 各版本功能差异

另外对于个版本差异有想简单了解的👬,可以阅读《1.5万字概括ES6全部特性[5]

通过一个实验,在 src/index.ts 文件中使用了 Map、Async/Await、Promise、扩展运算符,并在 tsconfig.jon -> target 设置为 ES5

验证 target 降级处理
验证 target 降级处理

然后发现在右侧的 dist/index.js 文件中,依然存在 new Map() 、Promise 语法,因此可以得出结论:tsc 的代码降级编译并不能完全处理兼容性

通过官方文档了解到:

这里提到了 lib 字段,意思是 target 不同的值会有对应默认的 lib 字段值,当然也支持开发者显示指明 lib 字段的值,那么接下来看看 lib 是干嘛的吧!

(2). lib

lib 字段是用于为了在我们的代码中显示的指明需要支持的 ECMAScript 语法或环境对应的类型声明文件。

例如我们的代码会使用到浏览器中的一些对象 windowdocument,这些全局对象 API 对于 TypeScript Complier 来说是不能识别的:

lib 未显示引入 DOM 会提示类型错误
lib 未显示引入 DOM 会提示类型错误

因而需要在 lib 字段中如下配置:

{
  "compilerOptions": {
    "target""ES5",
    "lib": ["ES5""ES6""DOM"],
  }
}

来显式引入在 DOM 即浏览器环境下的一些默认类型定义,即可在代码中使用,windowdocument 等浏览器环境中的对象,TS 在运行时以及编译时就不会报类型错误。

引入类型定义后无错误提示
引入类型定义后无错误提示

综合 targetlib 字段的实际功能表现,我们可以得出结论

TSC 的编译结果只有部分特性做了 pollyfill 处理,ES6[6] 的一些特性仍然被保留,想要支持完全的降级到 ES5 还是需要额外引入 pollyfill(也就是我们在项目的入口文件处 import 'core-js'),但建议是将 target 字段值设置为 ES6,提升 TSC 的速度。

因此,笔者对于使用 TSC 编译的观点是:

不应该将 TSC 作为编译项目的工具,应该将 TSC 作为类型检查工具,代码编译的工作尽量交给 RollupWebpackBabel 等打包工具!

另外推荐阅读《为什么说用 babel 编译 typescript 是更好的选择

(3). module

module 字段指明 tsc 编译后的代码应该符合何种“模块化方案”,可以指定的枚举值有:none, commonjs, amd, system, umd, es2015, es2020, 或 ESNext,默认值为 none

在如今的前端开发趋势来讲,主要是使用 ESM、CommonJS、UMD、IIFE 四种模块化方案,未来会趋向于 ESM,当然我们会根据项目的应用场景来决定使用何种模块化方案,例如:NodeJS 使用 CommonJS,浏览器里可以使用 ESM,不过现在的打包工具,会自动处理 CommonJS 和 ESM 的差异,并包装成符合指定模块化规范的代码,

在 tsconfig.json 可以设置 allowSyntheticDefaultImports 字段为 true,来允许合成默认导入。

(4). esModuleInterop

简单来说,就是支持合成默认导入。

在前端项目开发时,使用 ESM 编写代码引入了 CJS 的模块,由于 CJS 模块没有默认导出内容,因此需要通过我们的工具去自动化合成 CJS 的默认导出,以支持在 ESM 下流畅开发。

参阅文章《esModuleInterop 到底做了什么?[7]》,讲得非常详细也非常好。

esModuleInterop 字段设置为 true 时候,上述提到的 allowSyntheticDefaultImports 字段也会自动设置为 true

(5). moduleResolution

moduleResolution 声明如何处理模块,枚举值:classicnode,会根据 module 字段决定默认值。

推荐手动设置为 node,更符合现在大家的编码认识一些,而且大部分的构建打包工具都是基于 Node。

举个🌰,遇到 import {a} from 'a-lib'; 这样的模块引入代码应该如何去(解析)查找到对应的模块文件。

(6). baseUrl & paths

baseUrl:设置基本目录以解析非绝对模块名称(定义一个根目录,以此进行绝对文件路径解析)

paths:用于设置模块名或路径映射列表,这样就可以简写项目中自定义模块的文件路径。

举一个 🌰:

{
  "compilerOptions": {
    // 注意:baseUrl 必选,与 paths 成对出现,以 tsconfig.json 文件所在目录开始
    "baseUrl""."
    "paths": {
      // 映射列表
      "@/*": [
        "src/*"
      ],
      "moduleA": [
        "src/libs/moduleA"
      ]
    }
  }
}

// 代码里这么写
import Toast from '@/components/Toast.ts' // 模块实际位置: src/components/Toast.ts
import TestModule from 'moduleA/index.js' // 模块实际位置: src/libs/moduleA/index.js

⚠️ 注意: 如果需要自动生成(导出)类型定义文件,TSC 不会处理路径别名,需要引入 typescript-transform-paths[8] 插件,以及 TTypescript[9] 来转换路径别名为相对路径。

由于当前的 TypeScript 不支持 tsconfig.json 中的自定义转换器,且无法使用 tsc 命令使用自定义转换器编译文件,所以引入了 TTypescript 作为包装器

// tsconfig.json
{
  "compilerOptions": {
    "baseUrl""./",
    // 配置路径别名映射
    "paths": {
      "@/*": ["src/*"]
    },
    "plugins": [
      // 转换输出 js 文件中的路径
      { "transform""typescript-transform-paths" },

      // 转换输出 .d.ts 文件中的路径
      { "transform""typescript-transform-paths""afterDeclarations"true }
    ]
  }
}

plugins[10] 是用于扩展 TSC 编译器功能的字段。

例如在 Rollup 打包环境下,可以如下配置:

import typescript from '@rollup/plugin-typescript';
import ttypescript from 'ttypescript';

export default [
  {
    input'./src/index.ts',
    output: {
      dir'dist',
      format'cjs',
      entryFileNames'index.js',
    },
    plugins: [
      typescript({
        typescript: ttypescript,
      }),
    ],
  },
];

如果是有自动导出类型定义文件的需求,才需要搞这一套插件~

(7). rootDir & outDir

rootDir:指定 TypeScript 识别读取的根目录,用于所有非声明输入文件的最长公共路径

例如:'"rootDir": "./src",则 src 目录下的 TS 文件不能引用 src 目录以外的 ts 文件,一般我们会设置为 ./src./(即 tsconfig.json 所在目录)

outDir:输出目录,即 tsc 编译后的文件输出的文件夹路径(基于 tsconfig.json 文件的相对路径)

例如:"outDir": "./dist",及将 TSC 编译输出的 JS 文件,统一输出的 ./dist 目录下。

(8). jsx

如果是有 jsx 语法需要支持的项目,可以设置值 preservereact

{
  "compilerOptions": {
    "jsx""preserve"// 一般 preserve 即可
  },
}

(9). importHelpers

importHelpers 决定是否启用从 tslib 库引入语法降级辅助函数,以避免重复冗余的辅助函数声明。

个人建议是设置为 true 来启用。

(10).experimentalDecorators

experimentalDecorators 用于声明是否启实验性用装饰器模式。

TypeScript 和 ES6 中引入了 Class 的概念,同时在 Decorators[11] 提出了装饰器模式,通过引入装饰器模式,能极大简化书写代码。

当前对于 Decorator 的支持性不太好,如果是一些涉及到使用了装饰器的需要,就需要开启这个属性。

(11). noEmit

noEmit 设置是否输出 js 文件,一般是设置为 false,将打包等工作交给 Webpack 等工具。

三、tsconfig.json 全解析 📚

上面针对 tsconfig.json 中一些常见配置做了详细解释,将一些不常用的配置字段组合在一起,做一个 Checklist 如下:

{
  "compilerOptions": {
    /* 基本选项 */
    "target""es6"// 指定 ECMAScript 目标版本: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'
    "module""commonjs"// 指定使用模块: 'commonjs', 'amd', 'system', 'umd' or 'es2015'
    "lib": [], // 指定要包含在编译中的库文件
    "allowJs"true// 允许编译 javascript 文件
    "checkJs"true// 报告 javascript 文件中的错误
    "jsx""preserve"// 指定 jsx 代码的生成: 'preserve', 'react-native', or 'react'
    "declaration"true// 生成相应的 '.d.ts' 文件
    "declarationDir""./dist/types"// 生成的 '.d.ts' 文件保存文件夹
    "sourceMap"true// 生成相应的 '.map' 文件
    "outFile""./"// 将输出文件合并为一个文件
    "outDir""./dist"// 指定输出目录
    "rootDir""./"// 用来控制输出目录结构 --outDir.
    "removeComments"true// 删除编译后的所有的注释
    "noEmit"true// 不生成输出文件
    "importHelpers"true// 从 tslib 导入辅助工具函数
    "isolatedModules"true// 将每个文件做为单独的模块 (与 'ts.transpileModule' 类似).

    /* 严格的类型检查选项 */
    "strict"true// 启用所有严格类型检查选项
    "noImplicitAny"true// 在表达式和声明上有隐含的 any类型时报错
    "strictNullChecks"true// 启用严格的 null 检查
    "noImplicitThis"true// 当 this 表达式值为 any 类型的时候,生成一个错误
    "alwaysStrict"true// 以严格模式检查每个模块,并在每个文件里加入 'use strict'

    /* 额外的检查 */
    "noUnusedLocals"true// 有未使用的变量时,抛出错误
    "noUnusedParameters"true// 有未使用的参数时,抛出错误
    "noImplicitReturns"true// 并不是所有函数里的代码都有返回值时,抛出错误
    "noFallthroughCasesInSwitch"true// 报告switch语句的fallthrough错误。(即,不允许switch的case语句贯穿)

    /* 模块解析选项 */
    "moduleResolution""node"// 选择模块解析策略: 'node' (Node.js) or 'classic' (TypeScript pre-1.6)
    "baseUrl""./"// 用于解析非相对模块名称的基础目录
    "paths": {}, // 模块名到基于 baseUrl 的路径映射的列表
    "rootDirs": [], // 根文件夹列表,其组合内容表示项目运行时的结构内容
    "typeRoots": [], // 包含类型声明的文件列表
    "types": [], // 需要包含的类型声明文件名列表
    "allowSyntheticDefaultImports"true// 允许从没有设置默认导出的模块中默认导入。
    "esModuleInterop"true// 支持合成模块的默认导入
  
    /* Source Map Options */
    "sourceRoot""./"// 指定调试器应该找到 TypeScript 文件而不是源文件的位置
    "mapRoot""./"// 指定调试器应该找到映射文件而不是生成文件的位置
    "inlineSourceMap"true// 生成单个 soucemaps 文件,而不是将 sourcemaps 生成不同的文件
    "inlineSources"true// 将代码与 sourcemaps 生成到一个文件中,要求同时设置了 --inlineSourceMap 或 --sourceMap 属性

    /* 其他选项 */
    "experimentalDecorators"true// 启用装饰器
    "emitDecoratorMetadata"true // 为装饰器提供元数据的支持
  },
  /* 指定编译文件或排除指定编译文件 */
  "include": ["src/**/*"],
  "exclude": ["node_modules""**/*.spec.ts"],
  "files": ["index.ts""test.ts"],
  // 从另一个配置文件里继承配置
  "extends""@tsconfig/recommended",
  // 让 IDE 在保存文件的时候根据 tsconfig.json 重新生成文件
  "compileOnSave"true // 支持这个特性需要Visual Studio 2015, TypeScript 1.8.4 以上并且安装 atom-typescript 插件
}

四、打包工具中的 TypeScript 🦁

前文讲到了为什么不推荐直接使用 TSC 作为项目的打包编译工具,那么接下来就简单看看在常见的几款打包工具中针对 TypeScript 的编译方案是如何设计的?

4.1 Rollup + TypeScript

在 Rollup 打包中,我们一般只需要添加 @rollup/plugin-typescript[12] 插件即可,该插件会默认读取项目根目录下的 tsconfig.json 配置文件。

Rollup 的配置就像这样:

// file: rollup.config.js
import typescript from '@rollup/plugin-typescript';

export default {
  input'src/index.ts',
  output: {
    dir'output',
    format'cjs'
  },
  plugins: [typescript()]
};

结合其源码:

默认使用 TSC 作为 TS 的编译器
默认使用 TSC 作为 TS 的编译器

因为 typescript 声明了是 peerDependencies,因此会采用项目中安装的 typescript 版本,即是使用我们项目中的 TS 编译器。

通过阅读 @rollup/plugin-typescript 源码,可以看到该插件会默认使我们自己项目中的 tsconfig.json 文件作为 TSC 编译的配置,但会做一些配置预设覆盖:

会调用 ts.parseJsonConfigFileContent() 方法,将 FORCED_COMPILER_OPTIONS 值 merge 到用户的自定义配置中。

FORCED_COMPILER_OPTIONS
FORCED_COMPILER_OPTIONS

通过英文解释看到,因为需要 TSC 编译获得 JS 产物,所以会将 noEmit 设置为 false,也就是 TSC 编译会输出文件,但为什么我们在输出目录却没有看到对应的 TSC 产物呐?

TSC 编译结果存储到内存中
TSC 编译结果存储到内存中

但是如果开启了 declaration,则会将 TSC 解析得到的 *.d.ts 文件输出到指定目录。

4.2 Webpack + TypeScript

Webpack 中的 TypeScript[13] 官方文档中,指明了需要安装:typescriptts-loader 两个模块。

配置 Webpack 并支持 TypeScript 的配置如下:

// file: webpack.config.js
const path = require('path');

module.exports = {
  entry'./src/index.ts',
  module: {
    rules: [
      {
        test/\.tsx?$/,
        use'ts-loader',
        exclude/node_modules/,
      },
    ],
  },
  resolve: {
    extensions: ['.tsx''.ts''.js'],
  },
  output: {
    filename'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
};

可以看出 Webpack 主要是依赖 ts-loader 实现对 TypeScript 语法的编译支持,再看看对 ts-loader 的介绍:

ts-loader
ts-loader

换句话说,ts-loader 实际调用了 TSC 来编译 TS 文件,TSC 的配置依赖于你项目中的 tsconfig.json 文件。

如果使用了 Babel,则可以使用 @babel/preset-typescript[14] 来处理,但 Babel 不会做 TS 类型校验,在打包工具 Rollup 和 Webpack 中都可以引入 Babel,那么接下来看看 Babel 是如何处理 TypeScript 的吧!

4.3 Babel + TypeScript

Babel 处理 TS 需要安装 @babel/preset-typescript 模块,然后在 babel 项目配置文件中声明:

// 配置说明:https://babeljs.io/docs/en/babel-preset-typescript
{
  "presets": ["@babel/preset-typescript"]
}

但 Babel 中只会对 TS 代码转为 JS 代码(通过 parse TS 文件为 AST,并直接移除类型信息,然后打印目标代码),不会去做 TS 类型检查,所以 Babel 编译 TS 文件相较于 TSC 的速度更快!

同时,因为 Babel 会根据不同的兼容环境,按需引入 pollyfill,比 TSC 直接引入 core-js 更优雅,因此使用了 Babel 打包的体积也会更小。

TS 类型检查工作可以交给代码编辑器承担,当然同时可以新增 TS 检查的命令:

// package.json
{
  "script": {
    "tsCheck""tsc --noEmit",
  }
}

可以把类型检查放到特定的 npm scripts 生命周期之前,另外其实也可以将类型检查放到 git commit 阶段,用于做必要的 TS 类型检查,保证项目的正确性。

4.4 ESbuild + TypeScript

通过 Vite 体会到了 ESbuild[15] 带来的开发热更新“极速”体验,针对 TS 项目,ESbuild 和 Babel 是相同的编译策略,即仅编译,不校验类型

ESbuild 处理 TypeScript[16] 同样可以带来飞一般的感觉!

Vite 使用 esbuild 将 TypeScript 转译到 JavaScript,约是 tsc 速度的 20~30 倍,同时 HMR 更新反映到浏览器的时间小于 50ms。—— Vite Docs[17]

但在 ESbuild 中需要启用 tsconfig 中的 isolatedModules 功能,然后在类型引入的时候需要替换,规则参考如下:

// old
import { UserType } from './types';

// new
import type { UserType } from './types';

因为 ESbuild 是单独编译每个文件,无法判断引入的是 Type(类型) 还是 值,所以需要开发者显示地声明是“Type”。

同时还需要启用 esModuleInterop 功能,用于支持 ESM 模块合成默认导入,以兼容 CJS 和 ESM 规范。

另外 ESbuild 不支持:emitDecoratorMetadatconst enum 类型和 *.d.ts 文件

此外,关注到兼容性处理这方面,Bable 和 ESbuild 是类似的,因此会存在兼容性问题:

兼容性
兼容性

对于装饰器处理不支持,因为 TS 是 JS 的超集,ESnext 的规范提案某些还不是稳定的,因此如果有这方面诉求的项目,可以借助 TSC 做预编译,例如使用 Rollup 的 typescript 插件 或 Webpack 的 ts-loader 方式。

五、总结 📒

针对 TypeScript 项目的类型检查和编译流程算是完整过了一遍,相信已足以支撑大家在工作中自定义化配置 TS 前端项目!

另外,tsconfig.json 推荐配置策略如下:

  1. 借助 extends 字段,并结合项目应用场景,继承官方推荐配置
  2. 针对项目特点,按需修改对应功能配置
  3. 建议启用 importHelpersesModuleInterop,取消 noEmit 输出
  4. TS 项目的打包构建,推荐使用 Webpack、Rollup、Bable 等专业工具来保证正确性和构建优化

朋友们可以关注微信公众号:DYBOY,来一起玩耍呀~

参考资料

[1]

TSconfig.json 手册: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html

[2]

@tsconfig/recommended: https://www.npmjs.com/package/@tsconfig/recommended

[3]

TSconfig 最佳实践配置: https://github.com/tsconfig/bases/

[4]

ES.Next 语法提案: https://github.com/tc39/proposals

[5]

1.5万字概括ES6全部特性: https://watesegmentfault.com/a/1190000020678240

[6]

ES6 语法新特性: http://es6-features.org/#Constants

[7]

esModuleInterop 到底做了什么?: https://zhuanlan.zhihu.com/p/148081795

[8]

typescript-transform-paths: https://www.npmjs.com/package/typescript-transform-paths

[9]

TTypescript: https://www.npmjs.com/package/ttypescript

[10]

compilerOptions.plugins: https://www.typescriptlang.org/tsconfig#plugins

[11]

Decorators: https://github.com/tc39/proposal-decorators

[12]

@rollup/plugin-typescript: https://github.com/rollup/plugins/tree/master/packages/typescript/#readme

[13]

Webpack 中的 TypeScript: https://webpack.docschina.org/guides/typescript/

[14]

@babel/preset-typescript: https://babeljs.io/docs/en/babel-preset-typescript

[15]

ESbuild: https://esbuild.github.io/

[16]

ESbuild 处理 TypeScript: https://esbuild.github.io/content-types/#typescript

[17]

Vite Docs: https://cn.vitejs.dev/guide/features.html#typescript

DYBOY

2021/12/09  阅读:163  主题:自定义主题1

作者介绍

DYBOY