如何让Node.js NPM包原生支持TypeScript项目（无需全量重构为TS）

以下方案都不需要把整个代码库全量重写为TS，可以根据团队的维护成本、项目迭代节奏选择：

• 方案1：包内置独立类型声明文件
  完全不改动原有JS业务代码，在项目中新增专门的types目录，手写.d.ts类型声明文件，把所有对外暴露的类、方法、配置参数、返回值的类型都定义清楚。最后在package.json里添加"types": "./types/index.d.ts"字段指定类型入口，用户安装包之后TS就能自动识别到类型，不需要额外安装依赖。
  如果前期维护精力有限，也可以先把类型声明提交到DefinitelyTyped仓库，用户通过安装@types/memphis-dev获取类型支持，后续精力充足了再把类型迁移到包内内置即可。注意版本迭代的时候要同步更新类型声明，避免类型和实际API实现脱节。

• 方案2：通过JSDoc注解自动生成类型
  不需要修改文件后缀为TS，直接在现有JS代码中，给所有对外暴露的API补充标准JSDoc类型注释，标注清楚参数类型、返回值类型、结构定义。之后单独配置一份用于生成类型的tsconfig.json，开启allowJs: true、declaration: true、emitDeclarationOnly: true配置，调用TS编译器就能直接从带注释的JS代码中自动产出完整的.d.ts类型文件，最后在package.json中配置types字段指向生成的声明文件即可。
  这种方案改动成本极低，补充的JSDoc本身也能提升JS代码的可维护性，而且因为类型是从代码注释直接生成的，只要注释和代码保持同步，就不会出现手写声明容易出现的类型、实现不一致问题。

• 方案3：渐进式混合迁移
  不需要一次性把所有文件重构为TS，先给构建流程加上TS编译支持，配置允许.js和.ts文件共存。优先把对外暴露的入口文件、核心对外API模块改写为TS，内部不对外暴露的工具函数、底层逻辑可以长期保留JS，TS编译器本身支持混合编译两种类型的文件，构建时会正常输出兼容的JS产物和对应的类型声明文件。
  这种方案把重构成本拆分到了日常迭代里，不会因为一次性全量重构占用大量开发资源，也能避免大改动引入线上问题，最终用户拿到的类型体验和全量重构TS的包没有区别。

注意：无论选择哪种方案，发布前都建议本地写一个简单的TS测试demo，导入本地构建的包验证类型提示、类型校验是否符合预期，也可以在CI流程中加入简单的类型校验步骤，避免发布的版本出现类型错误。

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