如果我的包有这些依赖项
{ "name": "my-package",
"dependencies": { "foobar":"~1.0.3", "baz":"2.0.9" }
foobar
包有这些依赖
{ "name": "foobar",
"dependencies": { "baz":"^2.0.0" }
和baz
的最新发布版本是2.1.0
, yarn
的第一次运行将在foobar/node_modules
中安装baz@2.1.0
。
我如何强制纱线使用baz@2.0.9
包foobar
?
我的理解是,这将是可能的使用npm shrinkwrap
(就像这个问题)。
我的问题的总结可能是:Yarn创建了可重复的、确定的安装,但是我如何自定义该安装?
如果你确实有一个子依赖,它在接受的版本上有过多的限制,你可以使用yarn覆盖它们。
更新编辑: Yarn现在,作为1.0,正式支持"resolution "块。所以重写分辨率的方法就是添加这样一个block到package.json
:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
您有时会收到"不兼容"版本的警告,但我发现有些包(如socket.io)在接受的版本上过于限制,因此当它实际上不会破坏东西时,我会很高兴地选择最新版本。
下面是原创但过时的答案。
听起来原来的问题并不完全正确,但原来的问题实际上是我想要回答的问题,我找到了一个答案,所以这里是为子孙后代:
我正在使用套接字。io库,它有component-emitter
作为依赖项。但它需要两个版本。这就是纱线。
component-emitter@1.1.2:
version "1.1.2"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.1.2.tgz#296594f2753daa63996d2af08d15a95116c9aec3"
component-emitter@1.2.0:
version "1.2.0"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.0.tgz#ccd113a86388d06482d03de3fc7df98526ba8efe"
所以它包括两个副本的组件发射器在我的客户端代码。我看了看,在1.1.2和1.2.0(或1.2.1,这是当前的)之间似乎没有任何突破性的变化。我一开始只是试着换纱线。锁文件:
component-emitter@1.2.1, component-emitter@^1.2.1, component-emitter@1.1.2:
version "1.2.1"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.1.tgz#137918d6d78283f7df7a6b7c5a63e140e69425e6"
这是有效的,但是文件有关于它是自动生成的警告,这意味着我添加的每个更新或新包都会破坏这个更改。稍微搜索一下发现了yarn --flat
选项,这将迫使纱线在整个项目中选择不超过一个包。对我来说,这似乎有点小题大做,因为我确信新旧包之间确实存在不兼容的情况。我只是想从我的客户端代码中删除一个冗余包,使下载更小;我仍然希望所有的开发包工作正确。
但是在文档到yarn -flat中,我发现了一个"决议"块的引用,可以放在package.json中:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
所以我试着把"component-emitter" : "1.2.1"
放在一个新的"决议"块在我的包。实际上,对于所有需要它的地方,它都将component-emitter扁平化为1.2.1,现在我的客户端代码中只有一个副本。
(现在yarn
完全支持resolutions
块,所以你甚至不需要使用--flat
)
现在可以使用yarn的选择性版本分辨率特性。
在项目的主(根)package.json
中,使用resolutions
:
"resolutions": {
"foobar/**/baz": "2.0.9"
}
这将覆盖foobar
包(以及它下面的任何其他包)的baz
版本,强制它为2.0.9版本。
编辑:这是现在已弃用,请阅读这个答案:
https://stackoverflow.com/a/46615878/2398593@SomeCallMeTime的答案很好,我们已经在工作中做了一个月了。
不幸的是,自v0.24以来不再可能了。x(见注释)。
在Github上有一个开放的PR,其中有一个RFC建议有一种简单的方法来处理该用例,而不必关注生成的lockfile。