开发支持Node16的TypeScript库，@types/node依赖配置最佳实践

推荐把@types/node@^16.0.0同时配置在peerDependencies、peerDependenciesMeta和devDependencies中，既能解决消费者的类型缺失问题，又能最大程度避免版本冲突。具体配置和原因如下：

1. 配置peerDependencies + peerDependenciesMeta #

在你的package.json里添加：

"peerDependencies": {
  "@types/node": "^16.0.0"
},
"peerDependenciesMeta": {
  "@types/node": {
    "optional": true
  }
}

• 告诉消费者你的库适配的@types/node版本范围，但不会强制安装。消费者项目里如果已经有符合^16.0.0的版本，就用他们本地的；如果没有，npm 7+会自动补装兼容版本，旧版npm也不会报错。
• optional: true是核心：就算消费者用的是更高版本的@types/node（比如18、20），也不会触发编译错误——高版本的@types/node基本都向下兼容Node 16的类型定义，只要他们的Node版本不低于16，就不会有问题。

2. 把@types/node放进devDependencies #

同时在devDependencies里保留指定版本：

"devDependencies": {
  "@types/node": "^16.0.0"
}

这样你自己开发、编译库的时候，用的是固定的16版本类型，能保证库的类型输出严格符合Node 16的API范围，不会因为本地环境的高版本类型不小心引入Node 16不支持的API。

3. 为什么不放进dependencies？ #

如果把@types/node直接放进dependencies，消费者安装时会额外拉一份你指定的版本，很可能和他们项目里已有的@types/node重复，导致TS编译器遇到两份不同版本的Node类型声明，引发歧义错误。而且类型包属于开发依赖，没必要让消费者的生产依赖里包含它。

额外注意事项 #

• 在tsconfig.json里设置"target": "ES2021"（对应Node 16）、"lib": ["ES2021"]，确保代码只用到Node 16支持的API。
• 在库的README里明确标注最低支持Node 16，以及@types/node的版本要求，给消费者清晰的预期。

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