整理一下tsconfi相关的配置属性
TS Config
- files
- extends
- compilerOptions
-
- composite
- declaration✅
- declarationMap
- esModuleInterop❓
- forceConsistentCasingInFileNames
- inlineSources
这些配置项的功能后边打✅的是验证过的。打❓是不懂的
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