文档 / 语言手册 / 固定依赖
Edit

固定依赖

自 8.4 版本开始可用

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

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

包的类型

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

  • 顶层包(通常是你最后构建的 app,依赖于其他的包)

  • 固定依赖(这些是你的本地包,它们在构建顶层包时总是被重新构建,应该列在 bs-dependenciespinned-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 文件夹是我们的顶层包,它会使用 commonmyplugin 作为 pinned-dependenciesapp/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