Node.js 8环境下TypeScript的推荐配置咨询

我来帮你梳理下Node.js 8环境下TypeScript的最佳配置方案，解决你遇到的特性支持问题～

核心配置项解析与最佳取值 #

1. target #

target 指定TypeScript编译后的JS代码目标版本。Node.js 8内置的V8引擎是6.2版本，已经完整支持ES2017的绝大多数特性（比如async/await、Array.prototype.includes）。所以直接设置为"es2017"是最合理的——这样TS不会把Node.js已经原生支持的特性转译成更低版本的冗余代码，既保留原生性能，又减少编译开销。

如果设为"es6"，TS会把部分ES2017特性转译成ES6兼容代码，完全没必要，反而增加了不必要的编译步骤。

2. lib #

lib 用来指定TS编译时依赖的标准库类型声明。你之前遇到includes报错，是因为默认情况下TS会根据target推断lib：当target为es6时，默认lib只包含ES6的类型声明，而Array.prototype.includes是ES2016（别名ES7）的特性，所以会出现类型缺失。

针对Node.js 8，推荐设置"lib": ["es2017"]，这样能覆盖所有Node.js 8支持的ES标准库类型声明，彻底解决类似的类型错误。另外，如果你用到Node.js内置API（比如fs、http），记得安装@types/node来补充这些API的类型声明。

3. module #

module 指定编译后的模块系统。Node.js 8原生采用CommonJS模块规范，所以设置为"commonjs"是唯一适配的选择——编译后的代码能直接被Node.js识别加载，不需要额外的模块转换工具。

完整推荐配置 #

{
  "compilerOptions": {
    "target": "es2017",
    "module": "commonjs",
    "lib": ["es2017"],
    "strict": true, // 开启严格类型检查，提前发现潜在问题，推荐必开
    "esModuleInterop": true, // 解决CommonJS与ES模块的互兼容问题，比如import默认导出
    "skipLibCheck": true, // 跳过第三方库的类型检查，大幅提升编译速度
    "outDir": "./dist" // 指定编译输出目录，保持源码目录整洁
  },
  "include": ["src/**/*"], // 指定要编译的源码路径
  "exclude": ["node_modules", "dist"] // 排除无需编译的目录
}

为什么这个配置是最优的？ #

• 避免过度编译：target: es2017让TS仅处理Node.js 8不支持的特性（实际上几乎没有），编译后的代码更接近原生JS性能。
• 完整类型支持：lib: ["es2017"]完美匹配Node.js 8的ES特性覆盖范围，解决你遇到的includes这类类型缺失问题。
• 适配Node.js生态：module: commonjs确保编译后的代码直接在Node.js环境运行，无额外兼容成本。
• 增强开发体验：额外配置的strict、esModuleInterop等选项，能提升代码质量和模块兼容性。

关于你提到的lib: ["es7"]的问题 #

es7是es2016的别名，仅覆盖ES2016的特性，而Node.js 8已经支持ES2017的全部特性（比如async/await），用es2017比es7更准确，能避免ES2017特性的类型缺失问题。同时不用担心“定义过多特性”——因为Node.js 8已经原生支持这些特性，对应的类型声明完全匹配，不会出现不支持特性被错误声明的情况。

最后别忘了安装必要依赖：

npm install typescript @types/node --save-dev

内容的提问来源于stack exchange，提问作者Xenya