yarn 🚀 - 每次都重建本地包

无法在Mac OSX（10.11.6）中重现它，这可能是Ubuntu特有的问题吗？

jkimbo 于 2016-10-12

我可以在Windows 10上进行复制，但只能复制一次。第二次我运行“ yarn”时，它没有重建本机库。奇怪。

Daniel15 于 2016-10-13

我正在玩它，并想出了更多细节：

如果我运行yarn add leveldown bcrypt ，则将leveldown编译为列表中的第一项，并且完成后， node_modules/.yarn-integrity的哈希将等于595306... （剪切为了简洁起见，我认为这是一个校验和，用于确定是否需要执行某些操作。现在，如果我再次只运行yarn ，则将使用bcrypt编译为列表中的第一个软件包来重建这两个软件包（顺序不同）。结果校验和将等于cbe480... 。随后调用yarn不会重建软件包，并且校验和将保持不变。这与我的原始报告相矛盾（我可能在某个地方犯了错误），但与@ Daniel15看到的一致。
当我从一开始就颠倒软件包的顺序（ yarn add bcrypt leveldown ）时， bcrypt将在列表中排在第一位，并且产生的校验和将立即等于cbe480... 。随后调用yarn不会重建软件包。
不管列表中的位置如何， bcrypt软件包始终将首先完成（如预期的那样，因为编译的内容并不多）。

我一点都不熟悉内部结构，但在我看来，软件包的编译顺序很重要，并且在首次安装时根本不会对其进行排序（并且在稍后调用yarn时对它们进行了排序）这会以某种方式影响校验和。

jiripospisil 于 2016-10-15

👍4

感谢您的调查！听起来不错。哈希值写在这里： https ： .yarn-integrity的哈希值基于锁文件。

Daniel15 于 2016-10-15

可能值得调试该代码并查看锁定文件中的区别，因为.yarn-integrity中的哈希值基于锁定文件。

我怀疑，但是让我失望的是锁文件没有更改的事实，它始终是相同的。只是.yarn-integrity中的哈希值会发生变化。

$ yarn add leveldown bcrypt
$ cat node_modules/.yarn-integrity
59530680cc0a4ee12feb373980b5abf2edf2fe2aefa16d556bfb531af8299e71
$ cp yarn.lock leveldown_bcrypt_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock leveldown_bcrypt_afterwards.lock
$ diff -s leveldown_bcrypt_initial.lock leveldown_bcrypt_afterwards.lock
Files leveldown_bcrypt_initial.lock and leveldown_bcrypt_afterwards.lock are identical

$ yarn add bcrypt leveldown
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_afterwards.lock
$ diff -s bcrypt_leveldown_initial.lock bcrypt_leveldown_afterwards.lock
Files bcrypt_leveldown_initial.lock and bcrypt_leveldown_afterwards.lock are identical

$ diff -s leveldown_bcrypt_initial.lock bcrypt_leveldown_initial.lock
Files leveldown_bcrypt_initial.lock and bcrypt_leveldown_initial.lock are identical

jiripospisil 于 2016-10-15

我有同样的问题：我也使用bcrypt。每次我安装一些新模块或升级存在的模块时，都必须运行npm rebuild以使我的应用程序可运行。

macOS 10.12 &&节点v7.0.0 &&纱线v0.16.1

hustcer 于 2016-10-30

我无法再复制原始问题。似乎已被修复：+1:。 @ Daniel15您可以确认吗？

@小伙子我不认为这是同一个问题。如果您仍然无法使用最新版本，则可能要进行测试并提交新的错误。

jiripospisil 于 2016-11-17

@jiripospisil谢谢，升级到yarn v0.17.4之后现在可以了。

hustcer 于 2016-11-18

我仍然在0.18.1上看到这个或类似的东西。顺便说一句，也是降级，导致不断重复重建。出于说明目的，使用左键盘作为不依赖（且不受leveldown依赖）的程序包，再现步骤如下：

mkdir test && cd test
echo '{ "name": "test", "version": "1.0.0" }' > package.json
yarn add leveldown 
yarn add leftpad
yarn remove leftpad

运行此命令时，输出如下。请注意，卸下左垫板将花费近40秒钟，其中大部分时间是在重建降级状态时进行的。尽管仅在remove并且从未在add期间，但在Yarn缓存中是否有leveldown或leftpad的情况下，这始终发生。

$ mkdir test && cd test
$ echo '{ "name": "test", "version": "1.0.0" }' > package.json
$ yarn add leveldown 
yarn add v0.18.1
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 145 new dependencies.
<... package list omitted for brevity ...>
✨  Done in 49.93s.
$ yarn add leftpad
yarn add v0.18.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
✨  Done in 2.18s.
$ yarn remove leftpad
yarn remove v0.18.1
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
success Uninstalled packages.
✨  Done in 38.76s.
$ yarn why leftpad
<... just to confirm that leftpad and leveldown are entirely unrelated ...>
yarn why v0.18.1
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.30s.

版本：

节点v7.3.0
纱0.18.1
OS X El Capitan（10.11.6）

seansfkelley 于 2016-12-25

请重新打开，因为这仍然会发生。
只是做了yarn add redux而它重建了bcrypt ， node-sass和其他几个。

节点v6.9.4
纱线v0.20.3
Windows 10

ndraiman 于 2017-02-22

👍3

@seansfkelley我按照您的步骤操作了最新版本，并且该版本有效。你能再试一次吗？

/tmp/tp-20170222100611/test ∴ echo '{ "name": "test", "version": "1.0.0" }' > package.json
/tmp/tp-20170222100611/test ∴ yarn add leveldown
yarn add v0.20.3
info No lockfile found.
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 54 new dependencies.
<cut>
warning [email protected]: No license field
✨  Done in 1.64s.
/tmp/tp-20170222100611/test ∴ yarn add leftpad
yarn add v0.20.3
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
warning [email protected]: No license field
✨  Done in 0.69s.
/tmp/tp-20170222100611/test ∴ yarn remove leftpad
yarn remove v0.20.3
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
warning [email protected]: No license field
success Uninstalled packages.
✨  Done in 0.66s.
/tmp/tp-20170222100611/test ∴ yarn why leftpad
yarn why v0.20.3
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.20s.

@Nexxado您能否添加一些复制步骤？我尝试了几种组合，但效果很好。

节点7.3.0
纱线0.20.3
MacOS 10.12.3

jiripospisil 于 2017-02-22

@jiripospisil我没有提供复制的步骤，仅安装一个额外的程序包就可以使yarn链接并重建所有内容。

这是添加一个软件包的输出（锁定文件已存在）：

链接依赖项：
linking dependencies

重建：
rebuilding

ndraiman 于 2017-02-23

@jiripospisil我也仍然看到这种情况，但是在我的复制过程中，我跳了起来，因为它看起来像是降级（或其依赖项）可能已经开始发行与OS X兼容的二进制文件，因此安装时间从50s减少到了3s。如果您使用的是OS X，并且特别是yarn add [email protected]而不是yarn add leveldown ，则应该看到与以前相同的行为。

seansfkelley 于 2017-02-23

我对ttf2woff2有间接依赖性，它每次也会重新生成。

但是，仅在yarn.lock发生更改时才重新构建。也就是说， yarn具有新的yarn.lock ， yarn upgrade ， yarn upgrade-interactive 。在yarn upgrade-interactive情况下，如果devdeps和常规deps均被更新，则ttf2woff2将被重建两次（！）。

Jessidhia 于 2017-03-02

👍3

我也看到了这个问题，尽管我无法通过上述步骤重现它。但是，我可以通过以下步骤重现它：

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

加纱公司
```

然后再次建立降级功能。

我添加什么包似乎无关紧要，它始终可以重建leveldown。

我正在使用Yarn v0.21.3，Windows 10和Node v7.7.1

jefftimlin 于 2017-03-13

我也看到了我正在使用BuckleScript（bs-platform）....

jackalcooper 于 2017-03-13

👍6

我也遇到了sharp 。每次我运行yarn add或yarn remove ，即使使用非本地包，也将重建sharp 。

在Windows 10和Ubuntu Linux 16.04下的yarn v0.21.3，Node 7.0.0中进行了测试。

如果有帮助，这里是package.json依赖项：

{
  "devDependencies": {
    "auto-reload-brunch": "^2.7.1",
    "babel-brunch": "^6.1.1",
    "babel-preset-env": "^1.2.1",
    "brunch": "^2.10.8",
    "chai": "^3.5.0",
    "clean-css-brunch": "^2.10.0",
    "css-brunch": "^2.10.0",
    "express-mysql-session": "^1.2.0",
    "javascript-brunch": "^2.10.0",
    "jquery": "^3.1.1",
    "less-brunch": "^2.10.0",
    "mocha": "^3.2.0",
    "nodemon": "^1.11.0",
    "npm-run-all": "^4.0.2",
    "postcss-brunch": "^2.0.5",
    "postcss-cssnext": "^2.9.0",
    "postcss-font-magician": "^1.6.1",
    "uglify-js-brunch": "^2.10.0"
  },
  "dependencies": {
    "body-parser": "^1.17.1",
    "connect-redis": "^3.2.0",
    "cookie-parser": "^1.4.3",
    "debug": "^2.6.1",
    "express": "^4.15.2",
    "express-session": "^1.15.1",
    "jstransformer-marked": "^1.0.2",
    "md5": "^2.2.1",
    "morgan": "^1.8.1",
    "multer": "^1.3.0",
    "node-mysql": "^0.4.2",
    "passport": "^0.3.2",
    "passport-local": "^1.0.0",
    "pug": "^2.0.0-beta11",
    "serve-favicon": "^2.4.1",
    "sharp": "^0.17.2"
  }
}

tkesgar 于 2017-03-30

👍4

也看到bs-platform

svoynow 于 2017-04-19

👍3

同样，每次调用yarn add ttf2woff2都会遇到ttf2woff2即使一年没有发布，它也会重建

patrickhulce 于 2017-04-20

👍2

我也有这个沙发

编辑：似乎已在0.23.2中修复

technicallyfeasible 于 2017-04-21

我仍然在0.23.2上碰巧（ argon2和node-sass每次我添加/删除一些不相关的包（如moment都没有依赖项时都得到重建）

作业系统：Windows 10
节点：7.9.0
纱：0.23.2

raleksandar 于 2017-04-21

👍2

为了添加更多颜色，我对yarn add <some-package>发生的这种感觉比实际情况要大得多，因为对我来说，很多情况实际上是由于force: true之前与yarn remove <unrelated-package>相结合而触发的force: true在这条线上。

在remove中重用安装逻辑以生成锁定文件当然很方便，但是如果没有强制安装的全部负担，那将是很好的:)

patrickhulce 于 2017-04-25

对我来说，当我升级到0.23.x时，这又开始发生。我恢复为0.21.3，并且不再每次都构建。这也导致了这个问题，在连续升级几个软件包后，我的IP被unicode.org阻止了https://github.com/dodo/node-unicodetable/issues/16

kriscarle 于 2017-04-29

尽管0.21.3在添加新软件包时不会重建所有软件包，但在remove时会重建所有软件包。如果重建失败，似乎yarn不会认为它是失败的。

zhangjyr 于 2017-05-03

👍2

对我来说，降级为0.21.3没有帮助。 bs-platform将在每次添加/删除时重建。

akxcv 于 2017-05-06

👍2

在带有Yarn 0.23.4的macOS上看到了这一点。每次运行yarn add都会重建sqlite3 yarn add 。

$ yarn add gulp-rename gulp-notify gulp-sass -D                                                                                         1 ↵
yarn add v0.23.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning [email protected]: The platform "darwin" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
warning [email protected]: The platform "darwin" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 42 new dependencies.
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
└─ [email protected]
$ install-app-deps
Rebuilding native production dependencies for darwin:x64
Rebuilding native dependency sqlite3
✨  Done in 56.61s.

EthanMichaels 于 2017-05-16

👍2 👎1

在Ubuntu 16.04LTS，最新的yarn v0.24.6，节点8.1.2中看到此问题

我每次添加模块时都会看到gdal ， node-sass正在重建，这导致纱线添加花费的时间比必要的更长。

billxinli 于 2017-06-21

👍4

我也看到了这一点，在Raspberry Pi Zero W上超级令人讨厌，在该处构建包（如bleno）可能要花费几分钟。

richkzad 于 2017-06-22

👍1

仍然在Yarn v0.27.5和uws看到这一点。每当我的软件包中的某些内容发生更改时，都会重建uws。

关于uws ，我可以看到的唯一有趣的事情是，它在package.json中没有依赖项字段。

wmertens 于 2017-07-03

👍10

在过去的几天里，这让我很沮丧。我曾在一个阶段在全球安装windows-build-tools （只需要一次自我构建即可为本地软件包设置Windows开发环境），每次添加软件包时都会不断重新构建自身。可以想象，这花了很长时间，我最终意识到我不再需要安装它并删除它。

现在看来， node-sass在添加软件包时一直想在另一个预计的项目上进行重建。

对于我来说，此行为同时在yarn add和yarn remove上发生。这些步骤肯定不需要重新构建，因为按照Node版本只构建一次本地包？

编辑：在Windows 10上使用Node v8.2.1和Yarn v0.27.5

lostpebble 于 2017-07-31

我无法计算为我重建uws的次数:)请注意， uws
具有零依赖关系，甚至缺少package.json中的字段

2017年7月31日，星期一，晚上10:50 Paul Myburgh [email protected]
写道：

在过去的几天里，这让我很沮丧。我有
全局安装Windows-build-tools（实际上只需要
一次构建即可为本机设置Windows开发环境
软件包），每次添加软件包时都会不断重建自身。如
您可以想象这花了很长时间，但我最终意识到我没有
需要它已安装并删除。
现在看来，node-sass一直想在另一个预计的基础上重建
添加软件包时。
对于我来说，这种行为在添加和删除纱线时都会发生。当然没有
这些步骤需要重新构建，因为仅构建本机软件包
根据节点版本一次？
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/yarnpkg/yarn/issues/932#issuecomment-319192291或静音
线程
https://github.com/notifications/unsubscribe-auth/AADWlgSNhi-V9-yGWsWHBDFYdyJW8Arjks5sTj4UgaJpZM4KVN87
。

wmertens 于 2017-08-01

我使用的是0.27.5，并继续通过bs-platform看到此行为。

johannth 于 2017-08-08

这很令人沮丧，这里与bs-platform 。

constfun 于 2017-08-13

👍1

那里的权利感很好……PR Tim怎么样？

2017年8月22日星期二，上午10:44 Tim Shnaider [email protected]
写道：

FFS可以对此进行修复。
至少提供一个命令行选项或环境设置来禁用它。
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/yarnpkg/yarn/issues/932#issuecomment-323960245或静音
线程
https://github.com/notifications/unsubscribe-auth/AADWltQedG4owTlcC8koC4RL-vTiCE0Hks5sapTbgaJpZM4KVN87
。

wmertens 于 2017-08-22

👍4

到目前为止似乎还没有提到它，但是我也可以使用yarn global list来重现此错误。

重现步骤：

使用新的全局env：：警告：仅在知道自己在做什么的情况下运行此命令
```
rm -rf ~/.config/yarn/
```

添加有问题的软件包（_i.e._ zeppelin-solidity ）：

→ yarn global add node-gyp zeppelin-solidity
yarn global v0.27.5
[1/4] Resolving packages...
warning zeppelin-solidity > truffle-hdwallet-provider > web3-provider-engine > ethereumjs-block > merkle-patricia-tree > level-ws > xtend > [email protected]:
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Installed "[email protected]" with binaries:
      - node-gyp
warning "[email protected]" has no binaries
Done in 20.53s.

运行yarn global list并查看一些本机软件包正在重新编译
重复所需的次数， yarn global list将始终重新编译这些本机软件包
😭

我希望这有帮助。

Mac️MacOS 10.12.6带有通过Homebrew安装的Yarn 0.27.5。

michaelbaudino 于 2017-08-22

👍2

资格是不必要的，但是我可以理解它的挫败感。这浪费了很多人很多时间（长时间重新安装会随着时间的流逝而增加流量并中断流量）。当然，您可以说“发出拉取请求”-公平。但这将是一个可能仅需更改几行代码的学习过程。我们希望的是，了解此项目来龙去脉的人们可能会在下一版本中优先考虑此问题，因为它的确是似乎相当重要（并且可能很容易解决？如果Node版本未更改，请防止重新安装二进制文件）。

自从首次报道以来已经快一年了。

我希望我听起来没有资格这么说...我想补充一点，我非常感谢这个项目及其给我带来的有用性。这个问题是我遇到过的极少数痛苦之一。

编辑：只是做了一个随机软件包yarn remove ，它尝试了（这次）无法重建我的二进制文件。副作用是我的二进制文件现在完全丢失了，似乎唯一的解决方法是使用npm rebuild 。因此，不仅这个问题似乎导致不必要的重建-而且，如果该过程失败，则似乎您必须求助于npm来再次对其进行修复。

lostpebble 于 2017-08-23

👍13

我看到的行为与@zhangjyr和@lostpebble相同。运行yarn add可以正常工作，但是yarn remove可以重建本机软件包。

Mac Sierra 10.12.6
纱0.27.5

farism 于 2017-08-29

我将尝试看看对此我能做些什么，因为这也会影响我。也就是说，Yarn的贡献并不难，因此，如果有人想发送PR，请给它一个机会，我们会尽力为您提供支持。

我将在几周内无法进行此工作。

BYK 于 2017-08-29

👍8

我也看到了。
在gatsby上进行现场构建。任何纱线操作都会导致重建。
尝试使用gatsby创建网站并进行搜索。希望这可以帮助

Rulikkk 于 2017-09-11

👍1

在使用gatsby的项目中看到这一点：
纱线1.0.2
节点7.10.1
Ubuntu 16.04

AndyMoreland 于 2017-09-16

这个问题现在变得非常严重。我的二进制文件不仅总是被重建。但是经常发生的是，在yarn add或yarn install （更改package.json中的软件包的版本号以更新/回滚模块）之后，我的二进制文件被完全删除了。而且不管我多么运行yarn install或yarn install --check-files之后，这些二进制文件只是失去了和走了，永远不再回来。检索它们的唯一方法是使用npm rebuild 。

开始感觉好像yarn完全不了解本地程序包的状态。它们是否已经安装/构建，或者是否未正确安装/构建。

也许在这方面取得了任何进展？

lostpebble 于 2017-09-27

👍1

我认为@arcanis最近在纱线完整性文件中添加了artifacts字段将有助于解决此问题。尚无进展，但可以接受PR ：)

BYK 于 2017-09-27

👍1

在我的reasonml项目中安装软件包时，bs平台也有类似的问题

cullophid 于 2017-10-03

👍1

同样...实际上，每个yarn add都会重建gyp项目。

MeirionHughes 于 2017-10-13

👎1

也在这里发生。
（纱线1.2.1）

Okoyl 于 2017-10-22

👎1

我看到这与node-sass 。

jbrooksuk 于 2017-10-25

👎1

例如，发生在赛普拉斯身上。

节点-v
v8.8.1
纱-v
1.2.1

piehei 于 2017-10-26

👎1

✋除了在没有其他信息的情况下写“我也是”，还可以使用Github顶部文章中的+1功能。每次您写“我也是”评论时，都会不必要地通知35个订阅者。

sandstrom 于 2017-10-26

👍6

+1

HafizAhmedMoon 于 2017-10-26

👎9 😄3 😕2

如果要接收更新，请单击Subscribe 。我希望每个人都希望在解决问题时得到通知，但也不想在新手也遇到此问题时得到通知。

@BYK能否请您锁定线程，并使其仅对所有者可用。

printercu 于 2017-10-26

👍7

我目前正在调查此问题，并尝试将其归结为最小可重复的测试用例。用于演示此问题的“优质”软件包是htmlstrip-native -编译需要花费几分钟，因此您不会错过它。

我希望其他人在一个空文件夹中尝试此package.json ：

{
  "name": "yarn-test",
  "version": "1.0.0",
  "dependencies": {
    "htmlstrip-native": "^0.1.3",
    "left-pad": "1.1.3"
  }
}

尝试运行以下命令：

yarn
yarn upgrade [email protected]

在我的机器上，使用最新的yarn 1.2.1， upgrade命令会导致重建htmlstrip-native ，这将花费很长时间。纱线不应该重建它，因为升级left-pad对htmlstrip-native或其依赖项没有影响。

现在尝试npm ：

rm -rf node_modules
npm install
npm install [email protected]

在我的机器上，第二个命令（正确）不会导致重新生成htmlstrip-native 。

编辑：从重新阅读上面的所有帖子开始，对于任何人来说，这听起来都不奇怪-包括我自己在内的大多数人都发现，简单地要求yarn做_anything_会导致重建。我猜这不是社区中的大问题，因为大多数人不使用构建时间较长的本机软件包-因此他们要么没有重建步骤，要么完成得如此之快，以至于谁在乎。

nfarina 于 2017-10-26

👍4

好的，因此在进行大量调试之后，看来此行为是故意的。跟踪代码，例如，看起来像yarn upgrade [email protected]导致以下步骤：

1）调用upgrade模块，该模块为left-pad运行new Add()操作。
2） Add.init()调用其超类， Install.init()
3） Install.init()排队rebuildingPackages步骤
4）在PackageInstallScripts.init()它仅收集_all_软件包并将其添加到要重建的workQueue中。
5） PackageInstallScripts然后发现有一个用于htmlstrip-native的安装命令并运行它-这是我们都看到的超慢的本机重建。

从到目前为止我所看到的一切来看，似乎没有逻辑打算过滤掉不需要“重建”的软件包。如控制台输出中所述，它只是在重建所有内容。

我希望有一个来自Yarn团队的人来这里打铃-如果这种行为确实是故意的，那么我建议关闭此问题！

就我个人的情况而言，我将只换掉我的htmlstrip-native依赖关系，因为没有理由要花几分钟的时间来构建它（就像是几个小小的.c文件）。我的其他本机部门很快就会建立起来，因此，如果一直发生，这并不重要。

nfarina 于 2017-10-26

👍6

这听起来像是设计的意外副作用，但也许@ yarnpkg / core上的某人可以对此进行评论。我认为它不是要重建不需要重建的软件包。

Daniel15 于 2017-10-26

这不是故意的，以这种方式实现可能更容易。
BYK上面有一条评论，说这个问题正在寻找PR：
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

james-rabbit 于 2017-10-26

当然，本机较重的程序包不足以成为Yarn的最高优先级，但是Yarn有能力在每次安装时不重建程序包。
这似乎是一个应该立即修复，发送PR的错误。
可能会有一些警告，因为Yarn无法确定所构建的软件包是否已损坏，这就是为什么它现在急切地重新运行安装脚本。

团队在Reason https://github.com/esy-ocaml/esy-install之后使用了一个Yarn分支，该分支可解决许多本机编译问题，因为Reason / Ocaml依赖项需要大量编译。
随着这种方法的成熟，我希望可以合并上游的更改。

bestander 于 2017-10-30

👍4

因此，从根本上说，本机软件包是重建的，因为：

1）已设置force=true标志，或者
2）该程序包已标记为fresh=true 。

似乎有些命令（例如upgrade和remove ）将force标志设置为true，以防万一。该标志承诺“重建所有程序包，无论它们是否已更改”，因此添加一些更改检测代码没有意义，因为这会违反该承诺。

因此，要解决此问题，似乎我们将需要挑战设置force=true代码中各个地方的假设。

我跟踪到的第一个发生在运行yarn upgrade whatever 。 @juanca在此提交中将其作为＃2780的一部分进行了介绍。提交说明说：

"Ensure force flag is enabled when using `yarn upgrade` Otherwise exotic packages are not updated."

也许@juanca或更熟悉纱线历史的人可以解决这个原本打算解决的问题？

nfarina 于 2017-11-07

👍9

@nfarina谢谢，这很清楚。对于升级，也许我们真的想强制构建本机软件包（如果它们正在升级）。但是对于安装（纱线添加），我想说的是我们确实有必要挑战，正如您所说的那样，这种假设使已经安装的本机软件包在安装其他组件时得以重新构建。

yawaramin 于 2017-11-07

👍2

我想设置了force标志，以便Yarn解析器不会跳过现有的依赖项，因为旧版本位于yarn.lock中。

我认为这是使升级正常工作的快速解决方案。
正确的方法是传递另一个标志，该标志仅影响指定包的分辨率，并且不会像force那样具有核性。
发送公关:)

bestander 于 2017-11-13

也许@juanca或更熟悉纱线历史的人可以解决这个原本打算解决的问题？

正确，我只使用Add API －添加现有包时不执行任何操作。

我还建议使用更好的技术来控制程序流程。

juanca 于 2017-11-13

我在一个对node-opencv有依赖性的项目中的树莓派零上使用yarn。每次添加/删除/更新不相关的程序包时，我都必须等待35分钟才能进行重建。

Torsten85 于 2018-01-04

👍7 😄2 ❤1

@ Torsten85 ，我也在pi上使用它，是的，我们需要解决不必要的重建。
您可以提供重建脚本吗？

bestander 于 2018-01-04

👍1

同样在lubuntu 17.10上，当我使用yarn时，使用https://github.com/mui-org/material-ui进行开发

每一个yarn add/remove (-D) <pkg>重建所有内容（例如全新安装）超过1分钟

caub 于 2018-01-12

这也是npm的处理方式吗？如果不是，暂时切换是否可行？

rightaway 于 2018-01-21

👎2

也在这里发生

节点9.2.0
纱线1.4.0

每次添加一些依赖项时，每次都会重新构建bcrypt或couchbase之类的模块

rkmax 于 2018-01-29

👍1

大家好，我正在做一个小技巧https://github.com/yarnpkg/yarn/pull/5314。
这样做的想法是将已构建的程序包缓存到脱机镜像中，以避免一直运行安装脚本。

因此，如果您使用offline-mirror并运行yarn add node-sass ：

yarn会像往常一样建立并安装node-sass，
安装脚本运行后，它将从修改后的node_modules/node-sass文件夹生成node-sass-v4.7.2-darwin-x64-57.tgz
下次您在同一平台上运行yarn install时，将只解压缩node-sass-v4.7.2-darwin-x64-57.tgz而不是原始版本，并且将不会运行安装脚本

这并非在每种情况下都适用，但它可能是离线CI系统的解决方案，在这种系统中，您不希望软件包进入Internet并每次都运行相同的安装脚本。

bestander 于 2018-02-04

❤2 👍1

我正在尝试将打字稿安装为全局软件包，而yarn花费了所有时间来重建内容，而不是安装我现在真正需要的东西。

我转向纱线，认为它更快，更好。我删除了npm的任何痕迹（节点安装附带的内容除外）；并将所有全局软件包重新安装到yarn中。

Yarn现在通过让我等待1-15分钟以进行简单的软件包安装来测试我的耐心。纱线应足够聪明，以便在重建其他内容之前先安装请求的内容，除非请求的软件包明确依赖于任何需要重建的本机软件包。

环境：

节点：9.4.0
纱（全球）：1.3.2
macOS Sierra：10.12.6
Macbook pro 15英寸
- 记忆体：16 GB
- 处理器：2GHz-Intel Core i7
- 存储：代理（大量可用空间）
- 在安装时运行的应用程序：Firefox（6个选项卡），Mail.app和iTerm（具有2个选项卡）

日志

提取软件包需要很多时间

纱线全球升级打字稿
yarn global v1.3.2
[1/4]🔍解决包裹...
[2/4]🚚正在抓取包裹...
[############################################### ############ -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

链接依赖项卡住了几分钟，没有任何进展

纱线全球升级打字稿
yarn global v1.3.2
[1/4]🔍解决包裹...
[2/4]🚚正在抓取包裹...
[3/4]🔗链接依赖项...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

重建所有软件包-需要很多时间

纱线全球升级打字稿
yarn global v1.3.2
[1/4]🔍解决包裹...
[2/4]🚚正在抓取包裹...
[3/4]🔗链接依赖项...
[4/4]📃重建所有软件包...
[12/17]⠐websocket
[2/17]⠐表达：检查gcc选项以接受ISO C99 ...
[8/17]⠐串行端口：使用[email protected] | 达尔文| x64
[6/17]现在：>有关源代码，请查看： https :

纱线全球升级打字稿
yarn global v1.3.2
[1/4]🔍解决包裹...
[2/4]🚚正在抓取包裹...
[3/4]🔗链接依赖项...
[13/17] less无服务器
[13/17] less无服务器
[14/17]⠠solgraph
[14/17]⠁solgraph
[14/17]⡀solgraph
[-/ 17]⠈等待中...
[-/ 17]⠄等待中...
[-/ 17]⠠等待中...
[-/ 17]⠈等待中...
[-/ 17]⠄等待中...
[-/ 17]⢀等待中...
[-/ 17]⠈等待中...

我一直在等待:-)

abdul 于 2018-02-05

👍3

另一个副作用是，下载和缓存预编译的库也被擦除，必须再次下载：即nwjs-builder-phoenix的构建目标sdks缓存

MeirionHughes 于 2018-02-08

更新非本地软件包的软件包版本时，总是会重建本地软件包。

yarn是否像npm一样将二进制文件缓存到全局文件？

snowyu 于 2018-02-13

它开始让我有些沮丧，不得不在每个简单的安装中重建nwjs。没有意义

LuisHCK 于 2018-02-14

我也看到了。每当我执行添加/删除操作时，都会重新构建uws。纱线v1.3.2

Spongman 于 2018-02-16

嗨@bestander 我们已经在公司的monorepo上尝试了＃5314，但是它对我们停止某些依赖项的重建没有影响。我们已在.yarnrc中启用yarn-offline-mirror和pack-built-packages ，如添加的测试所示。

症结在于，即使我们之前直接运行的命令也是yarn ，运行yarn对我们来说总是要花费40-50秒。

bbrzoska 于 2018-02-19

👍2

@ bazyli-brzoska，我将标志更改为更加明确，并且忘记了更新说明。
您可以尝试将标志experimental-pack-script-packages-in-mirror设置为“ true”吗？

bestander 于 2018-02-21

在这方面有什么进展吗？我看到拉请求已被合并，并且它在最新版本1.5.1中。我使用的是1.5.1，什么都没有改变。不过，我正在考虑返回npm，因为等待322.70s或282.69s甚至683.41s （这些实际上是我的最后三个yarn add s）安装一个小的汇总插件或lodash或其他任何东西，简直太疯狂了。

如果在您的README.md上有这些警告，那就太好了。用户安装纱线是因为据称它是“更快”的，并且从npm过渡到纱线并不是一个小步骤，因此如果对开发人员有任何提前警告会很好，因此他们可以在转换之前再考虑一下他们的脚本，污染他们的全局对象并学习yarn cli。

我以为这只是我的旧32位机器的问题，但是看到它是第237次发生之后，我用谷歌搜索了，哦，yarn的速度并不快。大。

很抱歉，您可能会很卑鄙，但我认为您会感到沮丧。

nnmrts 于 2018-02-28

👍1

我们确实接受捐款。

话虽这么说，但在不需要“不需要”它们的情况下重新构建软件包时要记住一些事项：在安装依赖项之后执行构建步骤。这意味着允许构建脚本使用那些依赖项。这意味着，如果这些依赖项由于某种原因而发生更改（例如，如果我们将一个软件包的两个兼容版本优化为一个），则可能会“随机地”发生变化，那么我们实际上需要重新运行构建步骤，即使这些依赖项实际上并没有在构建过程中使用（因为我们怎么知道？）。

因此，这并不是一个简单的问题。问题的至少一部分来自package.json设计本身。告诉我有关挫败感的信息🙂

arcanis 于 2018-02-28

@arcanis我没有得到这一部分：

即使在构建过程中并没有真正使用那些依赖项（因为我们怎么知道？）。

我认为YARN的设计是保持静态依赖关系+版本（纱线锁定），因此不会有随机的“更新”。
即使json包给出了一棵完整的树，那么为什么您说“我们怎么知道”呢？一旦树被解析，就很容易说出，构建X的任何依赖项（甚至是深层次的依赖项）是否改变。

Rulikkk 于 2018-02-28

假设我有一个依赖项foo依赖于babel-core和left-pad@^1.0.0 ，并且这个foo依赖项具有一个在其索引文件上运行babel的构建脚本。

在项目文件夹中运行yarn add foo ，我最终在node_modules中拥有[email protected] ，对吗？现在，假设发布了新的左键盘版本（ 1.1.0 ），我想在项目中使用它。我将运行yarn add left-pad ，然后将其解析为latest ，即1.1.0 。

现在可能发生的事情是，Yarn将“看到”树中有两个左垫副本，并且还将看到它们可以被优化：毕竟， foo取决于left-pad@^1.0.0 ，因此1.1.0也兼容。因此它将删除以前的版本，并且仅使用1.1.0 。因为依赖关系已更改，所以我们需要再次运行构建脚本，因为Yarn无法知道left-pad是运行时依赖关系，而不是构建时间依赖关系。

现在您可能会问：“为什么在传递依赖项更改时不跳过重建？”。答案是某些软件包（尤其是本机软件包）具有从根本上影响其构建方式的依赖性。当发生这种情况时，我们真的很想重建那些软件包，否则最终将获得不兼容的工件。

arcanis 于 2018-02-28

@arcanis ，我想您误解了这个问题。这里的问题是，即使yarn快速连续运行两次（或更多次），这些本地软件包也会每次都被重建。它与依赖更新无关，它总是重建。

Spongman 于 2018-02-28

👍4

@Spongman我同意您的最新评论。但是正如@Spongman正确提到的那样，每次都会进行重建。即使您只执行yarn && yarn ，您也可以进行两次完整的重建，尽管事实并未改变依赖关系结构。

Rulikkk 于 2018-02-28

👍3

我尝试在OP中运行yarn add leveldown bcrypt && yarn && yarn ，但只有一个构建版本：/您是否有可以用来重现此行为的命令？

arcanis 于 2018-02-28

您可以尝试例如：

mkdir foobar
cd foobar
yarn init
....
yarn add socket.io
      (5 native packages build)
yarn add react
      (5 native packages build again)
yarn remove react
      (5 native packages build again)

（这是在Ubuntu 14 LTS下）

JesperWe 于 2018-02-28

👍1

foobar billli$ yarn -v
1.3.2
foobar billli$ node -v
v8.9.1

yarn & yarn

不会导致两次重建，但是在socket.io的示例中，添加react，删除react会导致两次重建

billxinli 于 2018-02-28

我尝试了用yarn v1.5.1的socket.io示例，并且在使用新功能来缓存本机版本时没有得到重建。为此，您需要使用脱机缓存。在我的~/.yarnrc我有：

experimental-pack-script-packages-in-mirror true
pack-built-packages true                                         
yarn-offline-mirror "/home/skomorokh/yarn-offline-cache"

当我尝试另一个没有该配置的用户时，它每次仍会重建。

skomorokh 于 2018-02-28

是的，添加这些选项后，现在无需重建。
但是，如果仅experimental-pack-script-packages-in-mirror true ，它仍然可以重建。
为什么不将yarn-offline-mirror设置为默认路径，例如“〜/ .yarn / cache”。

snowyu 于 2018-03-01

仍处于实验阶段，但这是一个有趣的建议（cc @bestander）。我想我遇到的问题是，我个人不喜欢未经用户明确同意而启用事物的想法。它还具有其他含义：将yarn-offline-mirror设置为false ，将experimental-pack-script-packages-in-mirror为true什么意思？ experimental-pack-script-packages-in-mirror覆盖yarn-offline-mirror设置吗？ imo有点混乱。

话虽这么说，添加left-pad uws时重建experimental-pack-script-packages-in-mirror设置是一种解决方法。我不确定下周左右是否有足够的资源来解决此问题，但是如果有人有兴趣修复此问题，那将非常有帮助。

arcanis 于 2018-03-01

👍1

@arcanis谢谢您的应该在您的README.md文件中提供有关此内容的信息，甚至

如果angularjs存储库的自述文件指出它是一个轻量级的框架，我也会感到同样的沮丧。不是。

nnmrts 于 2018-03-01

yarn-offline-mirror配置后，总是重复下载二进制文件。

cd \tmp\t
yarn init
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node

snowyu 于 2018-03-02

今天要尝试调试一下。我认为实际上可能只是简单地重建PackageInstallScripts而不检查pkg.fresh来重建新安装的软件包。相反，它似乎只是遍历所有对象。

rally25rs 于 2018-03-02

🎉3 👍1

经过一番摆弄之后，我开始认为我们一直在重建东西，以防有人rm -rf node_modules或从那里删除该模块。

我们在.yarn-integrity文件中列出了检测到的构建工件，因此我认为仅在fresh package || module destination dir does not exist || any file in integrity artifacts does not exist || --force flag was passed时才进行重建

因此，它比我想象的要复杂得多。

rally25rs 于 2018-03-02

我只是yarn add ed moment ，一个零依赖包，到我最新的react应用程序中，花了377.97s 。

之后再次执行此操作，它花费了389.63s并再次重建了二进制文件。

为了进行比较，我然后删除了node_modules并输入npm install ：
added 1751 packages and updated 124 packages in 360.595s

现在切换回npm。

nnmrts 于 2018-03-03

好的，关于此问题的更多信息供所有人关注...我已经花了整整一天半的时间弄弄这个东西，终于意识到了一些事情。

首先，大多数这些重建问题已得到解决。 PackageInstallScripts中已经有代码，仅重新运行软件包的安装脚本（如果标记为“ fresh”）：

    if (!ref.fresh && !this.force) {
      // this package hasn't been touched
      return false;
    }

因此，例如，如果您使用node-sass ：

yarn add node-sass <-- builds sass because first install
yarn add left-pad <-- does NOT rebuild node-sass

同样，连续的yarn install不会重建。

yarn add uws <-- builds because first install
rm -rf node_modules
yarn install <-- builds uws because dir was deleted
yarn install <-- does NOT rebuild uws

...但是当然有几个例外...

在yarn remove设置force标志（以修复我认为的某些其他错误，但是对于超过2年的用户则是如此），因此始终会进行重建。

但是，这可以说是“正确的”，因为这也是npm所做的：

~/Projects/yarn-test 🐒   npm uninstall left-pad

> [email protected] install /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/install.js

Cached binary found at /Users/me/.npm/node-sass/4.7.2/darwin-x64-57_binding.node

> [email protected] postinstall /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/build.js

Binary found at /Users/me/Projects/yarn-test/node_modules/node-sass/vendor/darwin-x64-57/binding.node
Testing binary
Binary is fine
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

added 180 packages, removed 1 package and updated 7 packages in 4.03s

您可以看到，在uninstall的left-pad ，npm为node-sass运行了install和postinstall脚本。

uws软件包（由其他许多软件包使用，如socket.io ， browser-sync等）。

在安装过程中，某些内容会更改文件之一（大小和时间戳不同）。

~/Projects/yarn-test 🐒   ls -l /Users/me/Library/Caches/Yarn/v1/npm-uws-9.14.0-fac8386befc33a7a3705cbd58dc47b430ca4dd95/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  383636 Nov 21 00:43 uws_darwin_57.node

~/Projects/yarn-test 🐒   ls -l node_modules/uws/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  378672 Mar  4 11:18 uws_darwin_57.node

yarn看到与高速缓存相比文件已“更改”，因此将软件包标记为“新鲜”以重新安装

然后，这触发了上面的逻辑，因为它是“新的”，因此会重新运行安装脚本。 Yarn试图提供帮助并“修复”不正确的文件，但是当然它不知道由于安装脚本而导致文件已更改。我们可能需要研究解决此问题的某种方法，但是也有谈论更改这些文件的比较方式（停止在每个文件上运行stat），因此可以通过重新工作来解决。

希望这可以解释某些情况下，有些人说它有用，而另一些人说不起作用。

rally25rs 于 2018-03-04

👍9 ❤3

感谢您深入那里，@ rally25rs。

回复：在删除命令中使用force 。
显然，这是一个快捷的漏洞修复程序，它通过IIRC的核方法https://github.com/yarnpkg/yarn/pull/323实现了正确性
应该不难删除force并解决此问题。
node_modules/uws/uws_darwin_57.node ：这个文件应该在artifacts的领域.yarn-integrity然后UWS不应该在连接过程中被标记为不新鲜。
这里可能有问题

bestander 于 2018-03-04

@bestander啊2点好。我会尝试看看是否有一种健全的方法来进行检查。

rally25rs 于 2018-03-04

stereokai 于 2018-03-19

@stereokai在上面的评论中，我注意到npm还会在卸载/删除时重建软件包，因此，如果您将npm的行为视为标准，那么这种情况可以说是“正确的”。

rally25rs 于 2018-03-19

@ rally25rs感谢您指出:)

但是，无论程序包管理器如何，我都认为此行为存在问题。很难理解为什么这种行为对于正确的操作甚至是必需的。当您添加/删除另一个本地程序时，您的操作系统不会重新安装本地程序，因为这些应用程序已经存在。我不希望静态依赖管理器有其他东西吗，nahmean？

stereokai 于 2018-03-20

👍1

@stereokai我有点同意，这就是为什么我使用“可以说是正确的”这个词组的原因😆
卸载不相关的应用程序时，您的操作系统也不会更改。

假设您有一些依赖树，例如：

myProj
  |- depA v1
  |    |-depB v2
  |- depB v1

如果安装此程序，则它将在node_modules下形成相同的目录结构，因为它无法将depB提升到根目录。

myProj
  |- node_modules
       |- depA v1
       |   |- node_modules
       |        |-depB v2
       |- depB v1

但是在您yarn remove depB ，新的dep结构为：

myProj
  |- depA v1
       |-depB v2

myProj
  |- node_modules
       |- depA v1
       |- depB v2

因此，每当添加或删除软件包时，安装depB v2的实际目录可能会更改。这些目录不只是从一个位置复制到另一个位置。删除旧的旧文件，然后将新的旧文件从缓存复制到新的目的地，这意味着node_modules/depA/node_modules/depB构建工件将不再存在，而需要在node_modules/depB重新构建。

同样， yarn add [email protected]会更改depB v2的安装路径（实际上，在这种情况下，我应该测试我的PR不会在yarn add上重建）

我怀疑这就是为什么每次都要重新构建这些软件包的原因。

实际更改发生在此提交中： https :
早在2016年。该文件当时的名称为uninstall.js ，但是force: true已添加到传递给install的标志中。提交注释中似乎没有任何特定内容指示_why_。

rally25rs 于 2018-03-20

👍2

如果有办法避免至少在某些情况下进行重建，那将会很棒。

lydell 于 2018-03-20

👍1

欢迎任何人从事公关工作。 I正如我在上文中指出的那样，在大多数情况下，在yarn install和yarn add上都不会进行重建。我打开了＃5470，当您的依赖项中有uws时（或其他在安装过程中更改其自身文件的软件包），应该消除yarn add不必要的重建。我所知道的唯一剩下的情况是yarn remove 。

rally25rs 于 2018-03-20

👍3

在阅读了大部分该线程之后，我不明白这里发生了什么。

每当我将yarn add用于任何其他（不相关）模块时，都会重建几个本地软件包。我的笔记本电脑上的CPU负载非常高，大约需要20分钟。我就是不能那样工作。

显然，从这个线程来看，这已经是19个月了。

是虫子吗？正在处理吗？有解决方法吗？我应该切换回npm吗？

vibl 于 2018-03-26

👍1

我应该切换回npm吗？

是的，直到发布＃5470。

Spongman 于 2018-03-26

@vibl

显然，从这个线程来看，这已经是19个月了。

实际上，它是很久以前修复的（大部分是修复的）。这个线程只是在几个星期前发现的一个极端情况下保持打开状态，如果该包更改了它的任何文件，该线程将重建一个包（与原始下载的文件相比，它认为文件是错误的，因此想修复）它）。对于remove和upgrade是否应该进行重建进行一些公开讨论（它在npm中进行，但也许不应该）

是虫子吗？

也许。哪些软件包正在重建？我所知道的唯一一个一直存在的问题是uws ，因此了解更多信息会有所帮助。

正在处理吗？

我上面提到的具体情况已在＃5470中修复

有解决方法吗？

如果您要添加的软件包没有任何安装脚本，则可以使用--ignore-scripts

或者，您可以从上述PR中签出分支并使用它。

大约需要20分钟

哇。我很好奇那是什么包裹。

rally25rs 于 2018-03-26

谢谢回答。

每次添加任何与yarn add无关的软件包时，软件包noise-search ， level-rocksdb和jq重新编译。我的笔记本电脑有点旧，因此需要很长时间才能同时编译它们。

我使用了纱线1.5.1和节点9.8.0。

vibl 于 2018-03-26

@vibl yeesh， noise-search绝对是冗长构建背后的元凶...

~/Projects/yarn-test 🐒   yarn add noise-search
yarn add v1.5.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 73 new dependencies.
✨  Done in 426.15s.

在MacbookPro上超过7分钟

无论如何，我安装了noise-search然后使用＃5470中的代码运行了yarn add left-pad ，它并没有引起重建，所以我认为一旦我们合并就可以了。

rally25rs 于 2018-03-26

谢谢：-）

我应该在几天，几周或几个月后重新检查Yarn吗？

vibl 于 2018-03-26

我刚刚发现，该错误在同一台笔记本电脑上具有相同的项目（双启动），在Windows 10上不会发生。但是在最新的三个Debian版本（Ubuntu，Arch Linux和Fedora）中都存在。奇怪的。尚未尝试MacOS，但似乎有些人在那里也遇到了问题。

nnmrts 于 2018-03-27

@vibl我不确定何时发布下一个版本（我不参与该计划）

@nnmrts是的，我发现这是操作系统特定的东西。根据我在＃5470中的评论：

在具有节点8的linux上，当文件从缓存复制到node_modules时，时间戳将更新。纱线确定文件不同并标记参考新鲜。
不过，这似乎仅在Linux节点8上发生。
这是因为Node v8.5引入了fs.copyFile，它使复制更快。 IIRC通过管道传输到本机文件系统副本，因此可以解释为什么它在操作系统之间以及仅在节点8中工作方式不同。

rally25rs 于 2018-03-27

👍1

@ rally25rs @nnmrts绝对不是MacOS特定的东西。在Win10 PC上也会发生

stereokai 于 2018-03-28

@stereokai好吧，这不是一个完整的问题。有时需要重建软件包，而人们仍然认为这是一个错误并将其发布在此处。没有每个操作系统的可靠，可复制的仓库，我们一无所知。

nnmrts 于 2018-03-28

从＃5314本地缓存构建的模块可能有帮助？：

使用以下命令将.yarnrc到您的项目中：

yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true

首次安装后，预构建的模块将位于./<your-offline-mirror-path>/prebuilt 。 yarn.lock也会使用预构建的变体进行更新

拉了最新的66a0143a753cd4ade1a0fffee2174890d564c129，看来工作正常😎

theandrewlane 于 2018-03-28

仍然重复下载二进制文件。

节点v6.13.1
纱线v1.6.0-20180327.1507
作业系统：Ubuntu 17.10 Linux 4.13.7-041307-generic
〜/ .yarnrc：


yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true


yarn add node-sass
yarn remove node-sass
yarn add node-sass

2018年3月29日，星期四，凌晨2:30，安德鲁·莱恩[email protected]
写道：

本地缓存已构建的模块（来自＃5314
https://github.com/yarnpkg/yarn/pull/5314 ）可能有帮助吗？：
使用以下命令将.yarnrc添加到您的项目中：
脱机镜“ ./”
实验包脚本包镜像中的true
首次安装后，预制模块将存在于
.//预建。 yarn.lock也被更新
带预建变体
拉了最新的66a0143
https://github.com/yarnpkg/yarn/commit/66a0143a753cd4ade1a0fffee2174890d564c129 ，
似乎工作正常😎
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/yarnpkg/yarn/issues/932#issuecomment-376989174或静音
线程
https://github.com/notifications/unsubscribe-auth/AAUAzz07Js-JQyj9n9_rsYq3cpd9Rp8qks5ti9a2gaJpZM4KVN87
。

snowyu 于 2018-03-29

@snowyu您删除了yarn.lock，node_modules和yarn cache clean吗？ ./yarn-offline-mirror/prebuilt是否在安装后填充？

theandrewlane 于 2018-03-29

这是一个临时的新项目。是的，我可以在缓存文件夹中看到node-sass-4.8.3.tgz文件。
现在，我运行yarn cache clean 。但是仍然会重复下载二进制文件* 。

``

纱线初始化
纱线添加节点
纱线添加v1.6.0-20180327.1507
信息找不到锁文件。
[1/4]解决包裹...
[2/4]正在获取软件包...
[3/4]链接依赖项...
[4/4]构建新的软件包...从https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node下载二进制文件
成功保存锁定文件。
成功保存了152个新的依赖项。
完成于11.98秒。

纱线添加节点
纱线添加v1.6.0-20180327.1507
[1/4]解决包裹...
[2/4]正在获取软件包...
[3/4]链接依赖项...
[4/4]构建新的软件包...从https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node下载二进制文件
成功保存锁定文件。
成功保存了1个新的依赖项。
信息直接依赖
└─[email protected]
info所有依赖项
└─[email protected]
在13.45秒内完成。
``

snowyu 于 2018-03-29

好吧，我做了简单的git repo重现此错误。

https://github.com/vlmonk/yarn-bug-test

当我尝试添加零依赖性left-pad时，yarn执行不必要的重建ttf2woff2 left-pad

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
yarn
[ ... building binary package here ... ]
yarn add left-pad
[ ... rebuilding binary packages here ... ]

我可以在主机OSX系统和docker容器中使用最新的node映像重现此图像

NPM在这种情况下可以正常工作：

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
npm i 
[ ... building binary package here ... ]
npm i left-pad
[ ... don't rebuild binary packages here ... ]

我的纱线版本1.5.1

vlmonk 于 2018-03-29

@vlmonk这是否仍然发生，如果你克隆https://github.com/rally25rs/yarn从@ rally25rs和＃5470（分公司使用的代码fix-linking-rebuilding-uws-932 ）？

karlhorky 于 2018-03-29

@karlhorky是的，yarn在添加left-pad之后仍然可以重建ttf2woff2 left-pad

# which yarn
yarn: aliased to node /Users/monk/work/yarn/lib/cli/index.js
# yarn --version
1.6.0-0

vlmonk 于 2018-03-29

ttf2woff2软件包带有在构建步骤中更改的文件。在下一次运行时，yarn会看到这些文件已更改，然后重新安装软件包。

Yarn应该更好地处理这种情况：应该看到在构建步骤中更改了这些文件，并且应该将这些更改的文件视为“正确”文件，而不是将它们视为重新安装的原因。

我用其他日志记录（https://github.com/sth/yarn/tree/trace-rebuild）进行了检查。首次安装时显示：

build artifacts for ttf2woff2
  modified file: build
  modified file: build/Makefile
  modified file: build/Release
  modified file: build/Release/.deps
  modified file: build/Release/.deps/Release
  modified file: build/Release/.deps/Release/addon.node.d
  modified file: build/Release/.deps/Release/obj.target
  modified file: build/Release/.deps/Release/obj.target/addon
  modified file: build/Release/.deps/Release/obj.target/addon/csrc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/addon.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/backward_references.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/block_splitter.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode_parallel.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/entropy_encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/histogram.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/literal_cost.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/metablock.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/streams.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/font.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/glyph.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/normalize.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/table_tags.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/transform.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/variable_length.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_common.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_enc.o.d
  modified file: build/Release/.deps/Release/obj.target/addon.node.d
  modified file: build/Release/addon.node
  modified file: build/Release/obj.target
  modified file: build/Release/obj.target/addon
  modified file: build/Release/obj.target/addon/csrc
  modified file: build/Release/obj.target/addon/csrc/addon.o
  modified file: build/Release/obj.target/addon/csrc/enc
  modified file: build/Release/obj.target/addon/csrc/enc/backward_references.o
  modified file: build/Release/obj.target/addon/csrc/enc/block_splitter.o
  modified file: build/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode_parallel.o
  modified file: build/Release/obj.target/addon/csrc/enc/entropy_encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/histogram.o
  modified file: build/Release/obj.target/addon/csrc/enc/literal_cost.o
  modified file: build/Release/obj.target/addon/csrc/enc/metablock.o
  modified file: build/Release/obj.target/addon/csrc/enc/streams.o
  modified file: build/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/obj.target/addon/csrc/woff2/font.o
  modified file: build/Release/obj.target/addon/csrc/woff2/glyph.o
  modified file: build/Release/obj.target/addon/csrc/woff2/normalize.o
  modified file: build/Release/obj.target/addon/csrc/woff2/table_tags.o
  modified file: build/Release/obj.target/addon/csrc/woff2/transform.o
  modified file: build/Release/obj.target/addon/csrc/woff2/variable_length.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_common.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_enc.o
  modified file: build/Release/obj.target/addon.node

软件包文件https://registry.npmjs.org/ttf2woff2/-//ttf2woff2-2.0.3.tgz实际上包含这些文件。

sth 于 2018-03-30

👍1

我们也可以在OS X上看到这一点，添加带有yarn add的任何软件包都会触发任何相关软件包的重新编译。我们有一个带有本机代码的node-gyp程序包，每次添加另一个程序包都需要1分钟以上的时间，而且本机模块中还没有太多代码（这会变得更糟）。这是纱线1.5.1。

如果有区别，我们将yarn add ../a与相对路径一起使用。

请让我知道是否有任何解决方法，或者什么时间可以解决。

cisaacson 于 2018-04-15

这是纱线1.5.1。

此问题已在1.6.0中修复，该问题已于近期发布。

BYK 于 2018-04-16

👍2

我仍然在1.6中看到这一点。自从npm移至yarn很久以前以来， uws一如既往地进行了重建（或至少yarn停留在uws大约5-10秒）。

重现步骤：

$纱线已过期
选择一个过时的包裹
$纱线升级[套餐]

grantila 于 2018-04-16

👍5

@grantila是否可以提供完整的package.json或存储库，并提供使用Yarn 1.6.0复制此步骤的步骤？

karlhorky 于 2018-04-16

这仍然在1.6.0上发生

您可以使用此https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784进行复制

sibelius 于 2018-04-25

👍1

我有一个简单的项目，我也看到了。添加或删除软件包似乎每次都会触发至少一个软件包的完全重建。

"dependencies": {
    "bufferutil": "3.0.4",
    "chance": "1.0.16",
    "discord.js": "11.3.2",
    "dog-facts": "1.0.3",
    "erlpack": "discordapp/erlpack",
    "flickr-sdk": "3.7.0",
    "html-entities": "1.2.1",
    "node-opus": "0.2.7",
    "snekfetch": "4.0.0",
    "sodium": "2.0.3",
    "utf-8-validate": "4.0.1"
  }

安装完这些后，我添加了unescape软件包，这触发了sodium的重建。然后我将其删除，从而触发了似乎需要编译的每个打包文件的重建。添加这个简单的程序包需要36秒，而删除它需要100秒！

编辑：在Debian Stretch上使用Node 8.11.1和yarn 1.6.0。

brenc 于 2018-04-29

@arcanis @ rally25rs请重新打开该问题，即使使用合并的修复程序，此问题仍在继续发生。

stereokai 于 2018-04-30

👍2

我认为这更多是@ rally25rs问题:)

BYK 于 2018-04-30

@grantila upgrade _ upgrade将会始终重建所有内容。这是故意的。 npm做同样的事情（我在这个长线程的某处的注释中提到了这一点。）尽管我们可能会尝试停止这样做。我不确定它可能会有什么影响。

其他所有人：

在＃5680中，我指出，如果程序包删除了自己的文件_（为什么哦，为什么要执行这些操作😿）_并且yarn无法在任何地方跟踪（我们跟踪创建或修改的文件），这种情况仍然会发生它只是认为该软件包丢失了文件并对其进行了重建。

我想我们可以重新打开它，但是对于大多数软件包来说，这个问题已经解决。如果有人想为此添加“我也”，请_please_提供您的package.json或特别提及哪个软件包正在不断重建，因为您可能有一些需要重建的依赖项，而有些则不需要。

欢迎任何人对此进行公关！（请参阅＃5680中的调试注释）

rally25rs 于 2018-04-30

👍1

抱歉，添加了更多噪音，但我想建议锁定此问题，并指向顶部具有最新信息的新问题。

我认为这里的问题已经转移了很多，至少已部分解决。有了这里的所有帖子，新手很难了解已修复的问题和仍然存在的问题。

james-rabbit 于 2018-04-30

👍5

我同意@ james-rabbit

stereokai 于 2018-05-01

是的，你是对的。我将锁定此锁，以使@ rally25rs的答案保持可见。

如果您对本机软件包有疑问：

如果所有本地依赖项
如果它发生在一个特定的本机依赖项上，请同时打开一个问题，但不要忘记在标题中指定依赖项的名称（如所解释的，由于不同的原因，可能会重新构建不同的软件包-为每个软件包保留一个问题使每个人都可以更轻松地共享信息）。

arcanis 于 2018-05-01

Yarn: 每次都重建本地包

最有用的评论

所有128条评论

相关问题