当.d.ts使用import x = require('...')模式导入typings()文件时,使用package.json typings
条目时语义会发生变化
.
例如,如果未使用package.json typings条目,则会成功导入以下声明文件,但Exported external package typings file is not a module在与typings条目一起使用时会生成错误TS2656():
declare module 'mymodule' {
export function myfunc(source: string): string;
}
Run Code Online (Sandbox Code Playgroud)
declare module {}当与package.json typings条目一起使用时,同一文件减去导入成功,但Cannot find module在没有typings条目的情况下使用时会生成错误TS2307().
export function myfunc(source: string): string;
Run Code Online (Sandbox Code Playgroud)
为什么语义的变化?
看起来如果你使用新的npm typings功能,你将必须维护你的打字文件的npm和非npm版本.
我试图在项目本身中使用项目打字文件时遇到这个问题(TypeScript没有在当前项目的package.json中查找typings条目,它似乎限制了它的搜索./node_modules).
使用TypeScript 1.7.5进行测试.
根据文档,typingspackage.json 中的键类似于main指向单个 Node.js 模块的键。因此,d.ts指向的文件也typings应该是单个导出的模块声明,而不是 d.ts 包。
文档给出的具体理由是:
\n\n\n基本原理是,类型不应将新的兼容源引入已编译文件集;否则源文件(即
\n.ts文件)将被编译器视为用户代码的一部分并被编译,并且包中的输出可以被结果输出覆盖.js。此外,加载类型不应通过从同一库的不同版本引入潜在冲突的条目来污染全局范围。模块有自己的作用域,并且不会污染全局命名空间,如果您的typings文件不是模块,它将污染用户全局作用域,并且会导致与依赖于您的包的其他包发生冲突。同样,
\n/// <references ... />可以将全局声明带入全局范围,应该避免。
(就我个人而言,像你一样,我认为这种实现是完全错误和愚蠢的。关键typings应该指向包含declare module \'./foo\' { \xe2\x80\xa6 }描述整个包的多个相对声明的单个文件,作为避免大量 TypeScript 特定文件污染文件系统的方法不幸的是,这艘船此时已经起航了,所以你的包只需要有大量 TypeScript 特定d.ts文件与你的 JavaScript 模块并排,再加上主模块 \xe2\x80\x99s 键入的冗余描述.)
| 归档时间: |
|
| 查看次数: |
639 次 |
| 最近记录: |