Node.js 如何从npm发布的模块导入流注释、类型和接口

我已经通过测试验证了两种模式可以从npm发布的模块导入流注释、类型和接口

在以下内容中，我将使用以下模块名称：

• 模块A：定义注释、类型和接口
• 模块B：依赖于模块A并希望对其进行类型检查，并使用其注释、类型和接口

模式1 模块A

• 将导出类型语法用于类型和接口：

  type IComplex ...
  interface IMutableComplex ...
  export type {IComplex, IMutableComplex}
  

• 将所有

  *.js

  文件复制为

  *.js.flow

  。例如，在

  package.json

  中包含以下内容：

  "main": "lib/index.js",
  "scripts": {
      "prepublish": "mkdir -p lib && for f in $(find src/ -iname *.js | cut -c5-) ; do cp src/$f lib/$f.flow; done",
      ...
   },
  

• 发布模块

模块B

• 由于发布模块的

  lib/

  目录中的

  js.flow

  文件，只需使用

  npm i--S module-A

  声明依赖关系，就可以使用注释
• 使用以下语法导入类型和接口：

  import type {IComplex, IMutableComplex} from 'module-A';
  

模式2 模块A

• 在

  decl

  目录下的

  declarations.js

  文件中定义类型、接口和模块（指向

  .flowconfig

  的

  [libs]

  部分）：

• 无需在

  预发布

  脚本中将

  *.js

  文件复制为

  *.js.flow

• 发布模块

模块B

• 使用

  npmi--S module-A

  像以前一样声明依赖关系。但是，这次没有可用的注释、类型和接口，因为“module-A”不包含任何

  *.js.flow

  文件，所以
• 从“module-A”包手动获取

  declarations.js

  文件，并将其放置在

  decl

  目录中（指向

  .flowconfig

  的

  [libs]

  部分
• 无需使用任何语法来导入类型和接口；它们将自动可用

以上两种模式是我发现的唯一方法，并且已经验证了它们的有效性（尽管我找不到全面的总结）

我的问题是：

哪种模式更惯用/更可取

还有其他模式吗

---

关于问题1，我可以看到，如果“模块A”由另一个组织/个人发布，“模式2”是唯一可能的方法。否则，如果一个组织/个人同时发布两个模块，我认为“模式1”更直接。

您的观察完全正确。以下是发布流类型定义的两种方法。没有其他方法可以做到这一点，或者更好：官方迁移计划将朝着两个方向发展，因为目前不可能强制所有JS项目都适应流

现在，“模式2”描述了我们称之为“libdef”文件或“声明文件”的内容。在该项目中，我们尝试为常见的第三方节点模块提供高质量的libdef文件

这两种模式都有其优点和缺点…vendoring

*.flow.js

文件的最大问题是，它们假定流的特定版本（例如PeerDependence flow bin不理解您最新使用的语法）。另一方面，这是一种更精简的方法，可以使类型与实际的代码库保持同步

无论如何，这两种方法都是有效的，只是要确保您的消费者不会仅仅为了您的软件包而被迫更改他们的

流

版本

另一些有用的信息：

flow@0.32

引入了一个名为

flow gen flow files

的实验性新功能，它将通过复制类型信息而不是整个代码，以更高效的方式创建

*.flow.js

另外，我在flow Type上创建了一个问题，在这里开始了完全相同的讨论：

---

干杯

它应该是

.js.flow

还是

.flow.js

？将

gen flow文件

集成到捆绑包（如汇总或网页包）中的推荐方法是什么？

type IComplex = { ...
interface IMutableComplex { ...
declare module "module-A" {
    declare function foo(i: number): number;
}