整理一下tsconfi相关的配置属性

这些配置项的功能后边打✅的是验证过的。打❓是不懂的

files

{
  "compilerOptions": {},
  "files": [
    "core.ts",
    "sys.ts",
    "types.ts",
    "scanner.ts",
    "parser.ts",
    "utilities.ts",
    "binder.ts",
    "checker.ts",
    "tsc.ts"
  ]
}

指定包含的项目里的文件，如果没有就会报错。
如果项目文件很少的时候可以用这个，更多的还是使用 include，exclude

extends

compilerOptions

composite

"compilerOptions": {
  "composite": false
},

这个选项强制了某些约束，使得构建工具（包括ts自己，在build模式下）能够快速确定项目是否已经构建完成

• 如果没手动设置rootDir，那么默认为包含tsconfig. json文件的目录
• 所有implementation文件必须与include或files下的内容是匹配的，如果违反了此约束，tsc将通知您没有指定哪些文件
• declaration 默认为true

declaration✅

默认值： false，如果开启了composite，则为true

"compilerOptions": {
  "declaration": true
},

生成*.d.ts文件

使用declaration 可能需要emitDeclarationOnly或者outDir属性确保JS文件不会被覆盖

declarationMap

"compilerOptions": {
  "declarationMap": true
},

生成*.d.ts文件的源映射
如果您正在使用project references，您应该强烈考虑打开此选项

esModuleInterop❓

默认值： 如果module是node16或者nodenext则为true，否则为false

"compilerOptions": {
  "esModuleInterop": true
},

默认情况下(esModuleInterop为false或未设置)，TypeScript对待CommonJS/AMD/UMD模块的方式与对待ES6模块类似。
在此过程中，有两个部分被证明是有缺陷的假设:

• 像import * as moment from "moment"这样的命名空间导入与const moment = require("moment")的作用相同。
• 像import moment from "moment"这样的默认导入与const moment = require("moment").default的作用相同

导致了两个问题

• ES6模块规范规定，命名空间import (import * as x)只能是一个对象，通过让TypeScript像对待= require("x")一样对待它，那么TypeScript就允许将导入作为一个函数来对待，并且可以被调用。这是无效的
• 虽然符合ES6模块规范，但大多数带有CommonJS/AMD/UMD模块的库并不像TypeScript的实现那样严格遵守规范。

esModuleInterop=true修复了这两个问题。第一个改变了编译器的行为，第二个是由两个新的辅助函数修复的，它们提供了一个缓冲，以确保所发出的JavaScript的兼容性。

forceConsistentCasingInFileNames

默认值： true

"compilerOptions": {
  "forceConsistentCasingInFileNames": true
},

区分文件名大小写

inlineSources

"compilerOptions": {
  "inlineSources": false
},

会把.ts文件的原始内容作为嵌入字符串包含在源映射中
这在与inlineSourceMap相同的情况下通常很有用

要求设置sourceMap或inlineSourceMap