纱线工作区-包别名

时间:2020-05-06 16:26:08

标签: node.js npm yarnpkg yarn-workspaces dependency-resolution

TL; DR如何为本地纱线工作区依赖性创建别名?

我之前曾经尝试过纱线工作区,但从未成功过,现在再尝试一次。

我在"workspaces": ["packages/*"]中设置了package.json

对于每个软件包,我决定使用命名约定@-/package-name来防止命名冲突,而不必担心内部软件包具有命名空间。

在将软件包添加为依赖项时,我一直遵循一种使用接口名称进行解析的样式,但是将其指向具体的实现。这是我在使用纱线工作区之前所做的:

"dependencies": {
  "my-interface-name": "file:some/path/to/packages/some-concrete-implementation"
}

这基本上是为了允许我喜欢所谓的编译时静态依赖注入。而且这还意味着每个程序包都可以根据需要单独命名其接口依赖项,并防止命名冲突。

但是,我无法弄清楚如何使用纱线工作区来完成此任务。如何为我的纱线工作区软件包@-/some-concrete-implementation创建一个名为my-interface-name的别名?

我已经尝试过但没有成功的东西:

  • "my-interface-name": "@-/some-concrete-implementation"}这样定义依赖项-由于某种原因,这会导致yarn在npm注册表中而不是在本地工作空间中寻找@-/some-concrete-implementation
  • 我还尝试过使用工作区协议:"my-interface-name": "workspace:@-/some-concrete-implementation"},但它仍在npm注册表中查找包!

我还没有尝试过并且可以工作的东西,但首先消除了使用纱线工作区的好处:

  • "dependencies": {"my-interface-name": "file:../../node_modules/@-/some-concrete-implementation"}"

1 个答案:

答案 0 :(得分:1)

您看过resolutions package.json key吗?是您需要的吗?

我已将其用于别名/覆盖外部软件包,但文档中的示例显示了它与本地软件包一起使用的情况。

解决方案

允许您覆盖特定嵌套依赖项的版本。有关完整规格,请参见Selective Versions Resolutions RFC

{
  "resolutions": {
    "transitive-package-1": "0.0.29",
    "transitive-package-2": "file:./local-forks/transitive-package-2",
    "dependencies-package-1/transitive-package-3": "^2.1.1"
  }
}

从RFC:

“ ** / a”表示项目的所有嵌套依赖项。

“ a”是** / a的别名(有关复古兼容性,请参见下文,因为如果不是这样的别名,它就没有任何意义,因为它将代表一个非嵌套的名称项目依赖项,如下所述不能被覆盖)。

所以,我认为您需要的规则是:

"**/my-interface-name": "file:some/path/to/packages/some-concrete-implementation"

// OR equivalent

"my-interface-name": "file:some/path/to/packages/some-concrete-implementation"

我相信它可以在包的package.json中使用。最坏的情况是您可以将其提升到工作空间的根目录并制定特定于该工作空间的规则,例如“ a / b”。