所以让我们想象一下我有一个 50 个文件模块,每个模块包含:
export class <SomeClassName> { /* content */ }
然后,我创建了一个根文件,通过重新导出所有文件来简化使用。所以它看起来像:
export * from "./src/some-class-1";
export * from "./src/some-class-2";
export * from "./src/some-class-3";
// etc
然后,我通过 TSC 运行它来执行一个针对“es5”的“通用”模块,并带有描述符输出。
到目前为止,一切都很好。我将我package.json
的名称my-module
目标index.js
作为模块的入口点输出。所以我现在决定在另一个打字稿项目中使用这个模块。
所以我为它进行了 npm 安装(让我们假装)npm install my-module
并且它都被引入了,所以我现在有了生成的 d.ts 文件,并且我有了实际的 commonjs 模块,所以我可以使用它。一切似乎都很好。
然后问题来了。然后我决定使用该模块:
import {SomeClass1} from 'my-module'
它像在 TS 世界中一样爆炸,它不知道与什么my-module
有关,好像我们回去看看输出的 index.js,它不包含环境模块。
所以问题来了,普通模块在包含模块名称时通常使用 package.json 作为参考点,但是 TS 使用 d.ts 文件。所以我想好吧,我需要将我的再导出包装index.ts
在一个模块中,所以我尝试:
export module "my-module" { /* all other re-exports */ }
但事实证明,您只能对环境模块使用字符串模块名称,并且只能将它们放在 d.ts 文件中,但是我的 d.ts 文件是从现有代码库生成的。
所以这是我的困境,我可以手动进入并在declare module "my-module
我的 d.ts 中添加一个包装器,但它不是很自动化,或者我确实喜欢使用 ES6 语法的博客文章并相对引用该文件,这最终会得到很多import {blah} from "../node_modules/my-module/dist/index"
,希望我们都能同意这有点愚蠢。
所以我找不到任何其他可以在自动化世界中工作的方法,因为当你使用 ES6 语法时,所有关于这个主题的博客文章和文档都使用相对文件导入,而不是从整个东西被编译和共享时导入通过 d.ts 文件。
那么这里有没有办法将我的重新导出包装在文本模块名称中?或者至少告诉 index.d.ts 包含在环境模块中?(请记住,它会为项目中的每个文件输出一个 d.ts 文件,但我们只关心通过 index.d.ts 导入模块,因为它会重新导出所有内容)。