yarn 🚀 - ネイティブパッケージは毎回再構築されます

これをMacOSX（10.11.6）で再現できないので、Ubuntu固有の問題である可能性がありますか？

jkimbo 2016年10月12日

Windows 10で再現できましたが、1回だけです。 2回目に「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 ：//github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/cli/commands/install.js#L581-L583。 .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確認できますか？

@hustcerそれは同じ問題ではないと思います。それでも機能しない場合は、最新バージョンでテストし、新しいバグを報告することをお勧めします。

jiripospisil 2016年11月17日

@jiripospisilありがとうございます。yarnv0.17.4にアップグレードした後は問題ありません。

hustcer 2016年11月18日

0.18.1で、これまたは非常によく似たものがまだ表示されています。ちなみに、何度も再構築され続けるのもレベルダウンです。実証目的で、依存関係のない（レベルダウンに依存しない）パッケージとしてleftpadを使用する場合、再現手順は次のとおりです。

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

これを実行したときの出力は次のとおりです。左パッドの取り外しには約40秒かかり、その大部分はレベルダウンの再構築であることに注意してください。これは、Yarnキャッシュにレベルダウンまたは左パッドがある場合とない場合で一貫して発生しますが、 remove間のみであり、 addません。

$ 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
ウィンドウズ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がすべてをリンクして再構築します。

1つのパッケージを追加した結果は次のとおりです（ロックファイルはすでに存在します）。

依存関係のリンク：
linking dependencies

再構築：
rebuilding

ndraiman 2017年02月23日

@jiripospisil私もまだこれを見ていますが、レベルダウン（またはその依存関係）がOS X互換のバイナリの出荷を開始したように見えるため、再現中につまずいたため、インストール時間が50秒から3秒に不審に減少しました。 OS Xを使用していて、 yarn add leveldownだけでなく特にyarn add [email protected]使用している場合は、以前と同じ動作が表示されるはずです。

seansfkelley 2017年02月23日

ttf2woff2に間接的に依存していますが、これも毎回再構築されます。

ただし、 yarn.lock変更があるたびにのみ再構築されます。つまり、 yarnに新しいyarn.lock 、 yarn upgrade 、 yarn upgrade-interactive追加されます。 yarn upgrade-interactive場合、devdepsと通常のdepsの両方が更新された場合、 ttf2woff2は2回再構築されます（！）。

Jessidhia 2017年03月02日

👍3

上記の手順では再現できませんでしたが、この問題も発生しています。ただし、次の手順で再現できます。

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

ヤーンアッドコ
`` `

その後、再びレベルダウンを構築します。

どのパッケージを追加するかは問題ではないようです。常にレベルダウンを再構築します。

Yarn v0.21.3、Windows 10、およびNodev7.7.1を使用しています

jefftimlin 2017年03月13日

私もこれを見ています。 BuckleScript（bs-platform）を使用しています...

jackalcooper 2017年03月13日

👍6

私もsharpこの問題に直面しています。 yarn addまたはyarn removeを実行するたびに、非ネイティブパッケージであっても、 sharpが再構築されます。

Windows10およびUbuntuLinux 16.04で、yarn v0.21.3、ノード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

また、でこれを経験してttf2woff2のすべての呼び出しyarn add再構築ttf2woff2 、それが年間に公開されていないにもかかわらず。

patrickhulce 2017年04月20日

👍2

私はこれもcouchbaseで持っています

編集：0.23.2で修正されたようです

technicallyfeasible 2017年04月21日

0.23.2でも発生します（依存関係のないmomentような無関係なパッケージを追加/削除するたびに、 argon2とnode-sassが再構築されます）

OS：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は、新しいパッケージの追加時にすべてのパッケージを再構築するわけではありませんが、削除時にすべてのパッケージを再構築します。そして、再構築が失敗した場合、yarnはそれを失敗とは見なさないようです。

zhangjyr 2017年05月03日

👍2

私にとって、 0.21.3へのダウングレードは役に立ちませんでした。 bs-platformは、追加/削除するたびに再構築されます。

akxcv 2017年05月06日

👍2

ヤーン0.23.4のmacOSでこれを見る。 yarn addを実行するたびにsqlite3構築します。

$ 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再構築されているのがわかります。これにより、yarnaddの実行に必要以上に時間がかかります。

billxinli 2017年06月21日

👍4

私もこれを見ています。パッケージ（blenoなど）のビルドに数分かかるRaspberry Pi ZeroWでは非常に煩わしいです。

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両方で発生します。ネイティブパッケージはノードバージョンに従って一度だけビルドされるので、これらのステップに再構築は必要ありませんか？

編集：Windows10でNodev8.2.1とYarnv0.27.5を使用します。

lostpebble 2017年07月31日

uwsが再構築された回数を数えることはできません:) uws注意してください
依存関係がなく、package.jsonのフィールドもありません

月、2017年7月31日には、10：50 PMポールMyburgh [email protected]
書きました：

これは、過去数日間、私にとってかなりのフラストレーションになりつつあります。私は持っていた
ある段階でグローバルにインストールされたwindows-build-tools（本当に必要なのは
自分自身を一度ビルドして、ネイティブ用のWindows開発環境をセットアップします
パッケージ）パッケージを追加するたびに自分自身を再構築し続けました。なので
あなたはそれがかなりの時間を要したことを想像することができます、そして私は最終的に私がしなかったことに気づきました
もうインストールして削除する必要があります。
今、node-sassは別の投影されたもので再構築したいと思っているようです
パッケージを追加するとき。
この動作は、私にとっては毛糸の追加と毛糸の除去の両方で発生します。確かにありません
ネイティブパッケージのみがビルドされるため、これらの手順には再構築が必要です
ノードバージョンごとに1回？
—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、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ティムはどうですか？

火、2017年8月22日には、10：44 AMティム・シュナイダー[email protected]
書きました：

FFSはこれを修正できますか？
少なくとも、コマンドラインオプションまたはenv設定を提供して無効にします。
—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、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このバグを再現することもできます。

再現する手順：

新しいグローバル環境を使用する::警告：これは、自分が何をしているかがわかっている場合にのみ実行してください
```
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は常にそれらのネイティブパッケージを再コンパイルします
😭

これがお役に立てば幸いです。

ℹ️MacOS10.12.6、Yarn0.27.5がHomebrew経由でインストールされています。

michaelbaudino 2017年08月22日

👍2

資格は不要ですが、欲求不満は理解できます。これは多くの人を多くの時間を浪費しています（長い再インストールは時間の経過とともに増加し、フローを中断します）。確かに、「プルリクエストを行う」と言うことができます-そしてそれは公正です。しかし、それは潜在的にほんの数行のコードを変更することに加えて学習プロセスになるでしょう...私たちが望んでいるのは、このプロジェクトの詳細を知っている人々が、次のリリースでこの問題を実際に優先する可能性があることですかなりメジャーに見えます（そして潜在的に簡単な修正ですか？ノードのバージョンが変更されていない場合は、バイナリを再インストールしないでください）。

それが最初に報告されてからもうすぐ1年になります。

私はそれを言う権利がないことを願っています...私はこのプロジェクトとそれがすでに私にもたらしている有用性に非常に感謝していることを付け加えたいと思います。この問題は、私が抱えていた数少ない問題の1つです。

編集：ランダムなパッケージに対して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

私もこれを見ています。
ギャツビーのサイト構築に取り組んでいます。糸の操作はすべて再構築を引き起こします。
ギャツビーでサイトを作成し、それを使ってヤーンしてみてください。お役に立てれば

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です。

ヤーンはネイティブパッケージの状態についてまったく知識がないように感じ始めています。それらがすでにインストール/ビルドされているかどうか、または正しくインストール/ビルドされていないかどうか。

これに関して何か進展があったのでしょうか？

lostpebble 2017年09月27日

👍1

@arcanisによる糸の整合性ファイルへの最近のartifactsフィールドの追加は、この問題の修正に役立つと思います。まだ進展はありませんが、PRにオープンです:)

BYK 2017年09月27日

👍1

私のreasonmlプロジェクトにパッケージをインストールするときにbs-platformで同様の問題が発生します

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]

私のマシンでは、最新のヤーン1.2.1を使用すると、 upgradeコマンドによってhtmlstrip-nativeが再構築され、これには永遠に時間がかかります。 left-padをアップグレードしても、 htmlstrip-nativeまたはその依存関係に影響がないため、Yarnはこれを再構築しないでください。

今すぐnpm試してください：

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

私のマシンでは、2番目のコマンドは（正しく） htmlstrip-native新規再構築にはなりません。

編集：上記のすべての投稿を読み直すと、このケースは誰にとっても驚くことではないように思えます-私を含め、ほとんどの人は、単に糸に_何か_をするように頼むと再構築されることに気づいています。ほとんどの人はビルドに長い時間がかかるネイティブパッケージを使用しないため、これはコミュニティでは大きな問題ではないと思います-したがって、再構築手順がないか、誰が気にするほど早く終了するかのどちらかです。

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日

これは意図的なものではなく、おそらくその方法で実装する方が簡単です。
この問題はPRを探しているというBYKからの上記のコメントがあります：
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

james-rabbit 2017年10月26日

確かに、ネイティブの重いパッケージは、Yarnの最優先事項として浮上するほど一般的ではありませんが、Yarnには、インストールのたびにパッケージを再構築しない機能があります。
これは、PRを送信して修正するのが簡単なバグのようです。
Yarnは、ビルドされたパッケージが破損している可能性があるかどうかを確実に知ることができないため、注意が必要な場合があります。そのため、現在、インストールスクリプトを熱心に再実行しています。

Reason / Ocamlの依存関係には大量のコンパイルが必要なため、Reasonhttps ：//github.com/esy-ocaml/esy-installの背後にあるチームが使用するYarnフォークがあります。これは多くのネイティブコンパイルの問題を回避します。
そのアプローチが成熟するにつれて、私は変更を上流にマージすることが可能になることを願っています。

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ありがとう、それは明快さをもたらします。アップグレードの場合、ネイティブパッケージを強制的にビルドしたいのかもしれません（アップグレードされている場合）。しかし、インストール（yarn add）の場合、あなたが言ったように、他の何かがインストールされたときにすでにインストールされているネイティブパッケージを再構築するという仮定に合法的に挑戦する必要があると思います。

yawaramin 2017年11月07日

👍2

古いバージョンがyarn.lockにあるため、Yarnリゾルバーが既存の依存関係をスキップしないようにforceフラグが設定されていると思います。

アップグレードを機能させるための迅速な解決策だったと思います。
適切な方法は、指定されたパッケージの解決にのみ影響し、 forceほど核的ではない別のフラグを渡すことです。
PRを送る:)

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では、糸を使用するときに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に取り組んでい
アイデアは、ビルドされたパッケージをオフラインミラーにキャッシュして、インストールスクリプトを常に実行しないようにすることです。

したがって、オフラインミラーを使用してyarn add 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システムのソリューションになる可能性があります。

bestander 2018年02月04日

❤2 👍1

私はtypescriptをグローバルパッケージとしてインストールしようとしていますが、yarnは、今本当に必要なものをインストールするのではなく、すべての時間を再構築に費やしています。

私はそれがより速く、そしてより良いと思って糸に移りました。 npmの痕跡をすべて削除しました（ノードのインストールに付属しているものを除く）。そして、すべてのグローバルパッケージをyarnに再インストールしました。

Yarnは現在、単純なパッケージのインストールを1〜15分待たせることで、私の忍耐力をテストしています。 Yarnは、要求されない限り、他のものを再構築する前に最初に要求をインストールするのに十分賢いはずです-パッケージは、再構築を必要とするネイティブパッケージのいずれかに明示的に依存します。

環境：

ノード：9.4.0
糸（グローバル）：1.3.2
macOS Sierra：10.12.6
Macbook pro15インチ
- メモリ：16 GB
- CPU：2GHz-Intel Core i7
- ストレージ：magentic（十分な空き容量）
- インストール時に実行されているアプリ：Firefox（6タブ）、Mail.app、およびiTerm（2タブ）

ログ

パッケージの取得には時間がかかります

ヤーングローバルアップグレードタイプスクリプト
ヤーングローバルv1.3.2
[1/4]🔍パッケージを解決しています...
[2/4]🚚パッケージの取得...
[################################################# ############ -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

依存関係のリンクが数分間進行せずにスタックしている

ヤーングローバルアップグレードタイプスクリプト
ヤーングローバルv1.3.2
[1/4]🔍パッケージを解決しています...
[2/4]🚚パッケージの取得...
[3/4]🔗依存関係のリンク...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

すべてのパッケージの再構築-多くの時間がかかります

ヤーングローバルアップグレードタイプスクリプト
ヤーングローバルv1.3.2
[1/4]🔍パッケージを解決しています...
[2/4]🚚パッケージの取得...
[3/4]🔗依存関係のリンク...
[4/4]📃すべてのパッケージを再構築しています...
[12/17]⠐websocket
[2/17]⠐expresso：ISOC99を受け入れるためのgccオプションのチェック...
[8/17]⠐シリアルポート：[email protected]を使用| ダーウィン| x64
[6/17]⠐今：>ソースコードについては、 https ：ください。

ヤーングローバルアップグレードタイプスクリプト
ヤーングローバルv1.3.2
[1/4]🔍パッケージを解決しています...
[2/4]🚚パッケージの取得...
[3/4]🔗依存関係のリンク...
[13/17]⠈サーバーレス
[13/17]⠂サーバーレス
[14/17]⠠ソルグラフ
[14/17]⠁ソルグラフ
[14/17]⡀ソルグラフ
[-/ 17]⠈待っています...
[-/ 17]⠄待っています...
[-/ 17]⠠待っています...
[-/ 17]⠈待っています...
[-/ 17]⠄待っています...
[-/ 17]⢀待っています...
[-/ 17]⠈待っています...

私は待ち続けます:-)

abdul 2018年02月05日

👍3

もう1つの副作用は、プリコンパイルをダウンロードしてキャッシュするライブラリもワイプされ、再度ダウンロードする必要があることです。つまり、ビルドターゲットSDKのnwjs-builder-phoenixのキャッシュです。

MeirionHughes 2018年02月08日

非ネイティブパッケージであるパッケージバージョンを更新すると、ネイティブパッケージは常に再構築されます。

ヤーンはバイナリをnpmのようにグローバルにキャッシュしますか？

snowyu 2018年02月13日

すべての単純なインストールでnwjsを再構築しなければならないことは私を少し苛立たせ始めます。意味がありません

LuisHCK 2018年02月14日

私もこれを見ています。 uwsは、追加/削除操作を行うたびに再構築されます。糸v1.3.2

Spongman 2018年02月16日

こんにちは@bestander。弊社のモノレポで＃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を使用していますが、何も変わりません。それでも、 322.70sまたは282.69s 、さらには683.41s （これらは実際には私の最後の3つのyarn add ）を待っているので、npmに戻ることを検討しています。小さなロールアッププラグインやlodashなどをインストールすることは、ほとんど何でも、非常識です。

これらのような主要な警告がREADME.mdにあるとしたら、それは素晴らしいことです。ユーザーはyarnをインストールします。これは、「高速」であり、npmからyarnへの移行は簡単なステップではないため、開発者に事前の警告があった場合は、変換する前にもう一度考えてみるとよいでしょう。彼らのスクリプト、彼らのグローバルを汚染し、糸のCLIを学びます。

これは私の古い32ビットマシンの問題だと思っていましたが、237回目に発生したのを見て、グーグルで検索しました。ああ、糸は速くありません。すごい。

意地悪でごめんなさい、でも欲求不満だと思います。

nnmrts 2018年02月28日

👍1

寄付は受け付けています。

そうは言っても、「必要」がないときに再構築されるパッケージに関して留意すべき点は、依存関係がインストールされた後にビルドステップが実行されることです。ビルドスクリプトがこれらの依存関係を使用できることを意味します。つまり、これらの依存関係が何らかの理由で変更された場合（たとえば、パッケージの2つの互換性のあるバージョンを1つに最適化した場合など、「ランダムに」発生する可能性があります）、これらの依存関係が実際にはない場合でも、実際にはビルド手順を再実行する必要があります。

したがって、それは必ずしも簡単な問題ではありません。問題の少なくとも一部は、package.jsonデザイン自体に起因します。欲求不満について教えてください🙂

arcanis 2018年02月28日

@arcanis私はこの部分を取得しません：

これらの依存関係がビルド中に実際に使用されていない場合でも（どうすればわかるのでしょうか？）。

YARNの設計は、静的な依存関係とバージョン（yarn-lock）を維持することであるため、ランダムな「更新」は発生しないと思いました。
パッケージjsonは完全なツリーを提供しますが、なぜ「どうやって知ることができるのか」と言うのですか？ツリーが解決されると、Xを構築するための依存関係（深いレベルの依存関係も含む）のいずれかが変更されたかどうかを簡単に判断できます。

Rulikkk 2018年02月28日

babel-coreとleft-pad@^1.0.0に依存する依存関係fooがあり、このfoo依存関係にインデックスファイルでbabelを実行するビルドスクリプトがあるとします。。

プロジェクトフォルダでyarn add fooを実行した後、node_modulesに[email protected]れることになります。ここで、新しい左パッドバージョン（ 1.1.0 ）がリリースされ、それをプロジェクトで使用したいとします。 yarn add left-pad実行すると、 latest 、つまり1.1.0ます。

これで、Yarnは、ツリーに左パッドのコピーが2つあることを「認識」し、それらを最適化できることも確認します。結局のところ、 fooはleft-pad@^1.0.0依存します。 1.1.0も互換性があります。したがって、以前のバージョンは削除され、 1.1.0のみが使用されます。依存関係が変更されたため、ビルドスクリプトを再度実行する必要があります。これは、 left-padがビルド時の依存関係ではなく、実行時の依存関係であることをYarnが知る方法がないためです。

ここで、「しかし、推移的な依存関係が変更されたときに、再構築をスキップしないのはなぜですか？」と尋ねるかもしれません。答えは、一部のパッケージ（特にネイティブパッケージ）には、ビルド方法に根本的に影響する依存関係があるということです。それが起こったとき、私たちは本当に本当にそれらのパッケージを再構築したいと思っています。さもないと、互換性のないアーティファクトになってしまいます。

arcanis 2018年02月28日

@arcanis 、私はあなたが問題を誤解していると思います。ここでの問題は、 yarnが2回（またはそれ以上）連続して実行された場合でも、これらのネイティブパッケージが毎回再構築されることです。依存関係の更新とは何の関係もありません-常に再構築します。

Spongman 2018年02月28日

👍4

@Spongman私はあなたの最新のコメントに同意します。しかし、 @ Spongmanが正しく述べたように、再構築は毎回行われます。 yarn && yarnだけを実行した場合でも、依存関係の構造に何も変更がないにもかかわらず、 2回の完全な再構築が行われます。

Rulikkk 2018年02月28日

👍3

OPのようにyarn add leveldown bcrypt && yarn && yarnを実行しようとしましたが、ビルドは1つしかありませんでした：/この動作を再現するために使用できるコマンドはありますか？

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

2回の再構築は発生していませんが、socket.ioの例では、reactを追加し、reactを削除すると、2回の再構築が発生します。

billxinli 2018年02月28日

ヤーン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親切な対応ありがとうございます。欲求不満は、糸が提示される方法から来ています。現時点では、「高速」ではなく、npmよりも高速ではなく、実際のプロジェクトでは使用できません。 イムホ、これに関する情報、またはこれが修正されるまで、README.mdファイルに@skomorokhによる回避策がある

anglejsリポジトリのreadmeに、軽量フレームワークであると記載されている場合、同じフラストレーションを感じるでしょう。そうではありません。

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編moment私の最新の、ゼロ依存パッケージをアプリに反応し、それが取った377.97s 。

その直後にもう一度やり直しました。 389.63sかかり、バイナリを再構築しました。

比較のために、node_modulesを削除して、 npm install 。
added 1751 packages and updated 124 packages in 360.595s

今すぐnpmに切り替えました。

nnmrts 2018年03月03日

OK、この問題に関するすべての目のためのいくつかのより多くの情報...私は1日半の間このことをいじっていて、ついにいくつかのことに気づきました。

まず、これらの再構築の問題のほとんどが修正されています。 PackageInstallScriptsは、パッケージのインストールスクリプトを再実行するだけのコードがすでにあり、「フレッシュ」とマークされています。

    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

left-pad uninstallで、npmがnode-sassに対してinstallおよびpostinstallスクリプトを実行したことがわかります。

uwsパッケージ（ socket.io 、 browser-syncなどの他のかなりの数のパッケージで使用されます...

インストールプロセス中に何かがファイルの1つを変更します（サイズとタイムスタンプが異なります）。

~/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は、誤ったファイルを助けて「修正」しようとしていますが、もちろん、インストールスクリプトが原因でファイルが変更されたことを認識していません。これを修正する方法を調査する必要があるかもしれませんが、これらのファイルの比較方法を変更する（すべてのファイルでstatの実行を停止する）という話もあるため、そのやり直しで解決される可能性があります。

うまくいけば、それがうまくいくと言う人もいれば、うまくいかないと言う人もいるここでのいくつかのケースを説明するでしょう。

rally25rs 2018年03月04日

👍9 ❤3

深く潜ってくれてありがとう、@ rally25rs。

再：削除コマンドでforceを使用します。
それは明らかに、核アプローチIIRChttps ： //github.com/yarnpkg/yarn/pull/323で正確さを達成したクイックカットコーナーバグ修正でした
forceを削除して、問題を回避するのは難しいことではありません。
node_modules/uws/uws_darwin_57.node ：このファイルは.yarn-integrity artifactsフィールドにある必要があり、リンク中にuwsがフレッシュでないとしてマークされないようにする必要があります。
ここで何かが間違っている可能性があります

bestander 2018年03月04日

@bestanderああ2の良い点。私は

rally25rs 2018年03月04日

stereokai 2018年03月19日

@stereokai上記の私のコメントでは、npmはアンインストール/削除時にパッケージも再構築するため、npmの動作を標準と見なす場合、このケースはほぼ間違いなく「正しい」

rally25rs 2018年03月19日

@ rally25rsそれを指摘してくれてありがとう:)

ただし、パッケージマネージャーに関係なく、この動作はバグがあると思います。正しく動作するためにこのような動作が必要な理由を理解するのは難しいです。アプリはすでに存在するため、別のプログラムを追加/削除しても、OSはローカルプログラムを再インストールしません。静的依存関係マネージャーに他に何も期待していません、nahmean？

stereokai 2018年03月20日

👍1

@stereokaiある程度同意するので、「ほぼ間違いなく正しい」というフレーズを使用しました😆
無関係なアプリケーションをアンインストールしても、OSは他のアプリケーションがインストールされている場所を変更しません。

次のような依存関係ツリーがあるとします。

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

これをインストールすると、 depBをルートに上げることができないため、 node_modules下に同じディレクトリ構造が形成されます。

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

そのため、パッケージが追加または削除されるたびに、depBv2がインストールされる実際のディレクトリが変更される可能性があります。これらのディレクトリは、ある場所から別の場所にコピーされるだけではありません。古いものは削除され、新しいものはキャッシュから新しい宛先にコピーされます。つまり、 node_modules/depA/node_modules/depBあったビルドアーティファクトは存在しなくなり、 node_modules/depBで再ビルドする必要があります。

同様に、 yarn add [email protected]は、 depB v2がインストールされているパスを変更します（実際、この場合、 yarn add再構築しないようにPRが実際に機能することをテストする必要があります）

それが、これらのパッケージが毎回再構築される理由だと思います。

実際の変更はこのコミットで発生しました： https ：
2016年にさかのぼります。ファイルの名前は当時uninstall.jsたが、 install渡されるフラグにforce: trueが追加されました。コミットコメントには、_理由_を示す具体的なものは何もないようです。

rally25rs 2018年03月20日

👍2

少なくとも_いくつかの_ケースで再構築を回避する方法があれば素晴らしいでしょう。

lydell 2018年03月20日

👍1

どなたでもPRにご参加いただけます。 😸上で指摘したように、再構築はyarn installとyarn add （ほとんどの場合）ではすでに発生していません。依存関係（またはインストール中に独自のファイルを変更する他のパッケージ）にuwsがある場合、 yarn add不要な再構築を排除する＃5470を開いています。私が知っている唯一の残りのケースは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ヶ月間問題になっています。

それは実際には（ほとんど）ずっと前に修正されました。このスレッドは、数週間前に見つけた1つのエッジケースで開いたままになります。この場合、パッケージがファイルのいずれかを変更した場合、yarnがパッケージを再構築します（元のダウンロードにあったものと比較してファイルが間違っていると思われるため、修正する必要があります）それ）。そして、 removeとupgradeが再構築を行うべきかどうかについてのいくつかのオープンな議論のために（npmで行いますが、おそらくそうではないはずです）

バグですか？

多分。どのパッケージが再構築されていますか？私が知っている唯一の問題はuwsであるため、詳細を知っておくと役に立ちます。

取り組んでいますか？

上記の特定のケースは＃5470で修正されています

回避策はありますか？

追加するパッケージにインストールスクリプトがない場合は、 --ignore-scripts使用できます。

または、上記のPRからブランチをチェックして、それを使用することもできます。

約20分かかります

ワオ。それがどんなパッケージなのか知りたいです。

rally25rs 2018年03月26日

回答ありがとうございます。

パッケージnoise-search 、 level-rocksdb 、およびjq 、 yarn add無関係なパッケージを追加するたびに再コンパイルされます。私のラップトップは少し古いので、同時にコンパイルするのに非常に長い時間がかかります。

Yarn1.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日

ありがとう:-)

数日、数週間、または数か月後にヤーンをチェックし直す必要がありますか？

vibl 2018年03月26日

同じラップトップ（デュアルブート）でまったく同じプロジェクトを使用するこのバグは、Windows 10では発生しないことを発見しました。しかし、最新の3つのDebianバージョン、Ubuntu、Arch Linux、Fedoraに存在します。奇妙な。 MacOSはまだ試していませんが、問題を抱えている人もいるようです。

nnmrts 2018年03月27日

@vibl次のリリースがいつになるか

@nnmrtsええ私はそれがOS固有のものであることを発見しました。＃5470の私のコメントから：

ノード8のLinuxでは、ファイルがキャッシュからnode_modulesにコピーされると、タイムスタンプが更新されます。ヤーンはファイルが異なると判断し、参照をフレッシュとしてマークします。
ただし、これはLinuxノード8でのみ発生するようです。
これは、ノードv8.5でfs.copyFileが導入され、コピーがはるかに高速になったためです。ネイティブファイルシステムコピーにパイプダウンするIIRC。これにより、OS間で、ノード8でのみ動作が異なる理由が説明されます。

rally25rs 2018年03月27日

👍1

rally25rsの@nnmrts @それはほとんど間違いなく、MacOSの固有のものではありません。私のWin10PCでも起こります

stereokai 2018年03月28日

@stereokaiええと、この問題全体は特定のものではありません。パッケージを再構築する必要がある場合もありますが、それでもバグだと思ってここに投稿します。すべてのOSに対して再現性のある確実なリポジトリがなければ、何も知ることができません。

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
OS：Ubuntu 17.10 Linux4.13.7-041307-汎用
〜/ .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

2時30分AMに木、2018年3月29日には、アンドリュー・レーン[email protected]
書きました：

ビルドされたモジュールをローカルにキャッシュする（＃5314から
https://github.com/yarnpkg/yarn/pull/5314 ）が役立つかもしれませんか？：
次のようにして、プロジェクトに.yarnrcを追加します。
ヤーンオフラインミラー "./「」
実験的パックスクリプト-パッケージインミラーtrue
最初のインストール後、ビルド済みのモジュールは
.// prebuilt。ヤーンロックも更新されます
ビルド済みのバリアント付き
最新の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を実行します。しかし、それでもバイナリを繰り返しダウンロードします* 。

`` `bash

糸の初期化-y
ヤーン追加ノード-sass
ヤーン追加v1.6.0-20180327.1507
infoロックファイルが見つかりません。
[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年代に行われました。

ヤーン追加ノード-sass
ヤーン追加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つの新しい依存関係を保存しました。
info直接の依存関係
└─[email protected]
infoすべての依存関係
└─[email protected]
13.45秒で完了。
「

snowyu 2018年03月29日

OK、このバグを再現するために簡単なgitリポジトリを作成しました。

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

糸行い、不要な再構築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システムと最新のnodeイメージを使用したDockerコンテナーの両方で再現できます。

この場合、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、糸はまだ再構築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

これはOSXでも見られ、 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は、Yarn 1.6.0これを再現する手順で完全なpackage.jsonまたはレポを提供できますか？

karlhorky 2018年04月16日

これは1.6.0でもまだ発生しています

このhttps://github.com/yarnpkg/yarn/issues/932#issuecomment-377112784を使用してこれを再現でき

sibelius 2018年04月25日

👍1

私は簡単なプロジェクトを持っていて、これも見ています。パッケージを追加または削除すると、毎回少なくとも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秒かかりました。

編集：DebianStretchでノード8.11.1とyarn1.6.0を使用します。

brenc 2018年04月29日

@arcanis @ rally25rsは問題を再開します。修正がマージされたとしても、これに関する複数の報告がまだ発生しています。

stereokai 2018年04月30日

👍2

これは@ rally25rsの問題だと思います:)

BYK 2018年04月30日

@grantila upgradeは、_常に_すべてを再構築します。これは意図的なものです。 npmは同じことをします（この長いスレッドのどこかのコメントでこれについて言及します）が、それをやめようとする可能性はあります。どのような影響があるのかわかりません。

他のみんな：

＃5680で、パッケージが自身のファイルを削除した場合でもこれが発生することを指摘します_（なぜ彼らはこれらのことを行うのですか😿）_そしてyarnはそれをどこでも追跡しません（どのファイルが作成または変更されたかを追跡します）。パッケージにファイルがないと判断して再構築するだけです。

これを再度開くことができると思いますが、これはほとんどのパッケージで修正されています。誰かがこれに「私も」を追加したい場合は、package.jsonを提供するか、再構築する依存関係と再構築しない依存関係がある可能性があるため、どのパッケージが継続的に再構築されているかを具体的に説明してください。

どなたでもPRできます！（＃5680のデバッグコメントを参照してください）

rally25rs 2018年04月30日

👍1

ノイズが増えて申し訳ありませんが、この問題をロックして、この最新情報を上部に表示した新しい問題を指摘することをお勧めします。

ここでの問題はかなり変化し、少なくとも部分的に解決されたと思います。ここにすべての投稿があるので、新しい人が修正されたものとまだ問題になっているものを最新のものにするのは困難です。

james-rabbit 2018年04月30日

👍5

@ james-rabbitに同意します

stereokai 2018年05月01日

はい、その通りです。 @ rally25rsの回答が表示されたままになるように、これをロックします。

ネイティブパッケージに問題がある場合：

すべてのネイティブ依存関係で発生する場合は、一般的な問題を開いてください。この問題は解決されているはずなので、すぐに発生することはないと思います。それでも、複製手順を提供できる場合は、新しい問題を開いてください（必要に応じてこの問題にリンクできます）。
特定のネイティブ依存関係で発生する場合は、問題を開いてください。ただし、タイトルに依存関係の名前を指定することを忘れないでください（説明したように、さまざまな理由でさまざまなパッケージが再構築される可能性があります。それぞれに1つの問題を保持します。誰もが情報を共有しやすくします）。

arcanis 2018年05月01日

Yarn: ネイティブパッケージは毎回再構築されます

最も参考になるコメント

全てのコメント128件

関連する問題