如何混合环境和非环境打字稿定义文件答案

【问题标题】：How to mix ambient and non-ambient typescript definition files如何混合环境和非环境打字稿定义文件
【发布时间】：2018-02-23 21:16:08
【问题描述】：

我有一个较旧的 typescript 项目，它使用 /typings/tsd.json 处理 .d.ts 文件的方法，并且还使用 Typescript 的 module 关键字将源代码编译为 javascript 的 IIFE 模块模式。该关键字会忽略 tsconfig.json (commonjs/amd/etc.) 中的模块设置。

作为一个演示，我正在向这个项目添加一些更新的打字稿代码，它使用更典型的 import 和 export 关键字方法和 SystemJS 模块加载器，在 /node_modules/@types 中带有 .d.ts 文件/。

经过一些 Gulp/SystemJS 体操，所有这些都在运行时协同工作，我有望赶上我的最后期限。但是在我想解决的一种情况下，我在编译时遇到了麻烦。

当我修改旧代码以使用新代码中的类（模型）时，我希望旧代码了解新代码的 .d.ts。所以我在旧代码文件的顶部添加了/// <reference path="../../newercode/feature4/models/NewerModels.d.ts"/>。（或者，我在 tsd.d.ts 中加入了相同的行，但得到了相同的结果。）

编译器抱怨我的旧代码“已经或正在使用私有名称'NewModel'”。

在 NewerModels.d.ts 中，import 和 export 关键字仍然存在，而 /typings/ 中的任何 .d.ts 文件都没有使用这些关键字。这些关键字是虚假编译器错误的罪魁祸首。

旧项目需要环境 .d.ts 文件，新代码生成非环境文件。

我能做些什么吗？

【问题讨论】：

我建议不要继续使用tsd，而是迁移到使用@types。您应该可以一口气做到这一点。
您为一个包获得的 .d.ts 文件会因您从哪里获得而有所不同。如果我这样做了，那么所有的 .d.ts 文件都会有 import/export 关键字，所以所有遗留代码都不会编译。
从@types 获得的较新文件应该具有相同的语法。原始库仍然是相同的 CommonJS 库（除非发生更改，否则您需要处理版本控制）。 tsd 从DefinitelyTyped 获取文件，与@types 相同。 TS 团队在转换格式方面做得相当不错。试试看它是否有效。
另一方面，您看到的错误是抱怨您没有导出NewModel。也许您没有将其包含在您的 package.json/dist 中？
好点，但遗留项目正在使用遗留 .d.ts，因此即使现在从两个来源接收到相同的 .d.ts 文件，旧项目也会针对旧 .d.ts 进行编译缺少麻烦的关键字。

标签： typescript module node-modules typescript-typings tsd

【解决方案1】：

我目前的解决方案并不理想，但它适用于演示目的。

我在 /typings/ 下创建一个新文件夹，名为 /feature4/，并将相关的 .d.ts 文件复制到其中.编辑它们以删除export 关键字，根据需要进行修改以删除import 关键字，并将class 关键字替换为interface 以防止修补的遗留代码尝试原始new NewerModel() 调用。

最后一点显然行不通，因为新的类实际上并不存在于全局命名空间中，而从 class 到 interface 的更改有助于阻止这种情况。因为我主要是抓取模型，所以除了要求将new NewerModel() 写为<NewerModel>{} 之外，界面不会失去任何功能，但我仍然可以在编译时检查模型的属性，这是我想要的 95% .

我也有一些服务以相同的方式处理，但是由于依赖注入，在它们上调用方法仍然有效。从一开始就从未从全局命名空间调用服务。

如果有人更改 /newercode/feature4/models/NewerModels.ts，这个解决方案显然会出现问题，但是 1）从现在到截止日期之间不应该有任何问题，以及 2）如果这确实是一个问题，我可以创建一个 Gulp 任务来自动复制和编辑每个构建上的 .d.ts 文件。

【讨论】：