我有一个较旧的typescript项目,它使用/typings/tsd.json方法处理.d.ts文件,并且还使用Typescript的module
关键字将源代码编译成javascript的IIFE模块模式。该关键字将忽略tsconfig.json(commonjs / amd / etc.)中的模块设置。
对于演示,我在这个项目中添加了一些较新的打字稿代码,它使用了import
和export
关键字与SystemJS模块加载器的更典型方法,其中包含.d.ts文件node_modules / @类型/。
当我修改旧代码以使用较新代码中的类(模型)时,我希望旧代码知道新代码的.d.ts。所以我添加到旧代码文件/// <reference path="../../newercode/feature4/models/NewerModels.d.ts"/>
的顶部。 (或者,我在tsd.d.ts中添加相同的行,但我得到相同的结果。)
编译器抱怨我的旧代码“已经或正在使用私有名称'NewModel'”。
在NewerModels.d.ts内部,import
和export
关键字仍然存在,而/ typings /中的.d.ts文件都没有使用这些关键字。这些关键字是虚假编译器错误的罪魁祸首。
旧项目需要环境.d.ts文件,较新的代码需要非环境。
我能做些什么吗?
答案 0 :(得分:0)
我目前的解决方案并不理想,但它适用于演示目的。
我在 / typings / 下创建了一个名为 / feature4 / 的新文件夹,并将相关的 .d.ts 文件复制到那里。修改它们以删除export
个关键字,根据需要进行修改以删除import
个关键字,并将class
关键字替换为interface
,以防止已修补的旧代码尝试使用原始new NewerModel()
1}}打电话。
最后一点显然不起作用,因为较新的类实际上并不存在于全局命名空间中,而从class
到interface
的更改有助于阻止这一点。由于我主要抓取模型,除了要求new NewerModel()
写为<NewerModel>{}
之外,接口不会失去任何功能,但我仍然可以对模型的属性进行编译时检查,这是95%的无论如何我想要的。
我也有一些服务以相同的方式处理,但由于依赖注入,调用它们的方法仍然有效。从来没有从全局命名空间调用服务。
如果有人更改 /newercode/feature4/models/NewerModels.ts ,此解决方案显然会出现问题,但1)现在和截止日期之间不应该存在任何问题,并且2)如果这真的是一个问题,我可以创建一个Gulp任务来自动复制和编辑每个构建上的 .d.ts 文件。