固定依赖

自 8.4 版本开始可用

通常我们推荐以单代码库风格使用 ReScript，这样可以通过单个 bsconfig.json 文件来管理你的整个代码库。

但是也有这样的场景，你想要为某个主要项目连接和构建多个独立的 ReScript 包（类似于 npm 工作区的 monorepos）。这就是 pinned-dependencies 发挥作用的地方。

包的类型

在我们讨论细节之前，首先说明一下构建系统识别的所有的包类型：

• 顶层包（通常是你最后构建的 app，依赖于其他的包）

• 固定依赖（这些是你的本地包，它们在构建顶层包时总是被重新构建，应该列在 bs-dependencies 和 pinned-dependencies 里）

• 普通依赖（这些是从 npm 获得的包，它们应该列在 bs-dependencies 里）

当一个包被构建时（rescript build），构建系统会构建顶层包和它的固定依赖。因此，在固定依赖中做的任何修改都会自动反映到最终的 app 中。

构建系统的包规则

对不同的包类型，构建系统遵循以下规则：

顶层包

• 报告警告

• 提示错误

• 构建 dev 依赖

• 构建固定依赖

• 使用自定义规则

• Package-specs（ES6/CommonJS）会覆盖所有依赖

固定依赖

• 报告警告

• 提示错误

• 构建 dev 依赖

• 忽略固定依赖

• 使用自定义规则

普通依赖

• 忽略警告和错误

• 忽略开发目录

• 忽略固定依赖

• 忽略自定义生成规则

记住这些知识，让我们深入更多具体的例子来理解固定依赖。

示例

Yarn 工作区

假设我们有一个这样的代码库：

myproject/
  app/
   - src/App.res
   - bsconfig.json
  common/
   - src/Header.res
   - bsconfig.json
  myplugin/
   - src/MyPlugin.res
   - bsconfig.json
  package.json

我们代码库根目录下的 package.json 文件像这样：

JSON
{
  "name": "myproject",
  "private": true,
  "workspaces": {
    "packages": [
      "app",
      "common",
      "myplugin"
    ]
  }
}

app 文件夹是我们的顶层包，它会使用 common 和 myplugin 作为 pinned-dependencies。app/bsconfig.json 配置看上去像这样：

JSON
{
  "name": "app",
  "version": "1.0.0",
  "sources": {
    "dir" : "src",
    "subdirs" : true
  },
  /* ... */
  "bs-dependencies": [
    "common",
    "myplugin"
  ],
  "pinned-dependencies": ["common", "myplugin"],
  /* ... */
}

现在，当我们在 app 包中运行 rescript build 时，编译器总是会重新构建它的固定依赖。

重要：ReScript 不会在 watch 模式中对任何的 pinned-dependencies 进行重新构建！因为文件监听很复杂，所以你需要建立自己的文件监听进程，在特定文件更改时运行 rescript build。