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

时间:2017-09-14 19:16:13

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

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

对于演示,我在这个项目中添加了一些较新的打字稿代码,它使用了importexport关键字与SystemJS模块加载器的更典型方法,其中包含.d.ts文件node_modules / @类型/。

在经历了一些Gulp / SystemJS体操后,它们在运行时一起工作,我正按计划进入最后期限。但是我在编译时遇到麻烦,在一个我想解决的场景中。

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

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

在NewerModels.d.ts内部,importexport关键字仍然存在,而/ typings /中的.d.ts文件都没有使用这些关键字。这些关键字是虚假编译器错误的罪魁祸首。

旧项目需要环境.d.ts文件,较新的代码需要非环境。

我能做些什么吗?

1 个答案:

答案 0 :(得分:0)

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

我在 / typings / 下创建了一个名为 / feature4 / 的新文件夹,并将相关的 .d.ts 文件复制到那里。修改它们以删除export个关键字,根据需要进行修改以删除import个关键字,并将class关键字替换为interface,以防止已修补的旧代码尝试使用原始new NewerModel() 1}}打电话。

最后一点显然不起作用,因为较新的类实际上并不存在于全局命名空间中,而从classinterface的更改有助于阻止这一点。由于我主要抓取模型,除了要求new NewerModel()写为<NewerModel>{}之外,接口不会失去任何功能,但我仍然可以对模型的属性进行编译时检查,这是95%的无论如何我想要的。

我也有一些服务以相同的方式处理,但由于依赖注入,调用它们的方法仍然有效。从来没有从全局命名空间调用服务。

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