Yarn: Paket asli dibuat ulang setiap saat

Tidak dapat mereproduksi ini di Mac OSX (10.11.6) jadi mungkin masalah khusus Ubuntu?

Saya dapat melakukan repro di Windows 10, tetapi hanya sekali. Kedua kalinya saya menjalankan "benang", itu tidak membangun kembali perpustakaan asli. Aneh.

Saya bermain-main dengannya lagi dan menemukan beberapa detail lagi:

1. Jika saya menjalankan yarn add leveldown bcrypt , leveldown akan dikompilasi sebagai item pertama dalam daftar dan hash dalam node_modules/.yarn-integrity akan sama dengan 595306... setelah selesai (potong untuk singkatnya; Saya berasumsi itu adalah checksum yang menentukan apakah sesuatu perlu dilakukan). Sekarang jika saya menjalankan hanya yarn lagi, kedua paket akan dibangun kembali dengan bcrypt dikompilasi sebagai yang pertama dalam daftar (urutannya berbeda). Checksum yang dihasilkan akan sama dengan cbe480... . Pemanggilan yarn tidak akan membuat ulang paket dan checksum akan tetap sama. Ini bertentangan dengan laporan asli saya (saya mungkin membuat kesalahan di suatu tempat) tetapi sejalan dengan apa yang dilihat @ Daniel15 .
2. Ketika saya membalik urutan paket langsung dari awal ( yarn add bcrypt leveldown ), bcrypt akan menjadi yang pertama dalam daftar dan checksum yang dihasilkan akan langsung sama dengan cbe480... . Pemanggilan yarn tidak akan membuat ulang paket.
3. Paket bcrypt akan selalu selesai pertama (seperti yang diharapkan karena tidak banyak yang harus dikompilasi) terlepas dari posisinya dalam daftar.

Saya sama sekali tidak terbiasa dengan internal tetapi menurut saya urutan di mana paket-paket dikompilasi penting dan mereka tidak disortir ketika pertama kali diinstal (dan mereka _are_ diurutkan ketika kemudian meminta yarn ) yang mempengaruhi checksum dalam beberapa cara.

Terima kasih telah menyelidiki! Kedengarannya seperti petunjuk yang bagus. Hash ditulis di sini: https://github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/cli/commands/install.js#L581 -L583. Mungkin layak untuk men-debug kode itu dan melihat apa yang berbeda di lockfile, karena hash di .yarn-integrity didasarkan dari lockfile.

Mungkin ada baiknya men-debug kode itu dan melihat apa yang berbeda di lockfile, karena hash dalam .yarn-integrity didasarkan pada lockfile.

Saya curiga, tetapi yang membuat saya bingung adalah kenyataan bahwa file kunci tidak berubah, selalu sama. Hanya hash dalam integritas .yarn yang berubah.

$ 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

Saya memiliki masalah yang sama: Saya juga menggunakan bcrypt. Setiap kali saya menginstal beberapa modul baru atau mengupgrade yang sudah ada, saya harus menjalankan npm rebuild agar aplikasi saya dapat dijalankan.

macOS 10.12 && node v7.0.0 && benang v0.16.1

Saya tidak dapat lagi mereproduksi masalah aslinya. Sepertinya sudah diperbaiki: +1 :. @ Daniel15 Bisakah Anda mengkonfirmasi?

@ penjual Saya tidak berpikir itu masalah yang sama. Anda mungkin ingin menguji dengan versi terbaru dan melaporkan bug baru jika masih tidak berhasil untuk Anda.

@jiripospisil Terima kasih, Tidak apa-apa sekarang setelah memutakhirkan ke benang v0.17.4.

Saya masih melihat ini, atau yang sangat mirip, di 0.18.1. Kebetulan, itu juga leveldown yang terus dibangun kembali berulang kali. Menggunakan leftpad sebagai paket tanpa dependensi (dan yang tidak bergantung pada leveldown) untuk tujuan demonstrasi, langkah-langkah repro adalah sebagai berikut:

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

Output saya ketika saya menjalankan ini sebagai berikut. Perhatikan bahwa menghapus leftpad membutuhkan waktu hampir 40 detik, yang sebagian besar adalah membangun kembali leveldown. Ini terjadi secara konsisten, dengan dan tanpa leveldown atau leftpad di cache Benang, meskipun hanya selama remove dan tidak pernah 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.

Versi:

Node v7.3.0
Benang 0.18.1
OS X El Capitan (10.11.6)

Harap buka kembali karena ini masih terjadi.
Baru saja melakukan yarn add redux dan membangun kembali bcrypt , node-sass dan beberapa lainnya.

Node v6.9.4
Benang v0.20.3
Windows 10

@seansfkelley Saya mengikuti langkah Anda dengan versi terbaru dan berhasil. Bisakah Anda mencoba lagi?

/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 Bisakah Anda menambahkan beberapa langkah reproduksi? Saya mencoba beberapa kombinasi tetapi berhasil.

Node 7.3.0
Benang 0.20.3
MacOS 10.12.3

@jiripospisil Saya tidak memiliki langkah-langkah reproduksi yang harus disediakan, cukup dengan menginstal paket tambahan menyebabkan benang menghubungkan dan membangun kembali semuanya.

Berikut output dari penambahan satu paket (file kunci sudah ada):

Menautkan dependensi:

Pembangunan kembali:

@jiripospisil Saya juga masih melihat ini, tetapi selama repro saya, saya tersandung karena sepertinya leveldown (atau ketergantungannya) mungkin telah mulai mengirimkan biner yang kompatibel dengan OS X, sehingga waktu penginstalan turun secara mencurigakan dari 50-an menjadi 3s. Jika Anda menggunakan OS X dan Anda secara khusus yarn add [email protected] bukan hanya yarn add leveldown , Anda akan melihat perilaku yang sama seperti sebelumnya.

Saya memiliki ketergantungan tidak langsung pada ttf2woff2 , yang juga membangun kembali setiap saat.

Namun, itu hanya membangun kembali setiap kali ada perubahan ke yarn.lock . Yaitu, yarn dengan yarn.lock , yarn upgrade , yarn upgrade-interactive . Dalam kasus yarn upgrade-interactive , jika devdep dan deps reguler diperbarui, ttf2woff2 akan dibangun ulang dua kali (!).

Saya juga melihat masalah ini, meskipun saya tidak dapat mereproduksinya dengan langkah-langkah di atas. Namun saya dapat mereproduksinya dengan langkah-langkah ini:

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

benang tambahkan co
``

sekali lagi itu membangun leveldown.

Tidak peduli paket apa yang saya tambahkan, itu selalu membangun kembali leveldown.

Saya menggunakan Yarn v0.21.3, Windows 10, dan Node v7.7.1

Saya melihat ini juga. Saya menggunakan BuckleScript (bs-platform) ....

Saya mengalami masalah ini juga, dengan sharp . Setiap kali saya menjalankan yarn add atau yarn remove , sharp akan dibangun kembali, bahkan dengan paket non-native.

Diuji di benang v0.21.3, Node 7.0.0, di bawah Windows 10 dan Ubuntu Linux 16.04.

Berikut adalah package.json dependensi, jika itu membantu:

{
  "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"
  }
}

juga melihat ini dengan bs-platform

Juga mengalami hal ini dengan ttf2woff2 setiap panggilan ke yarn add membangun kembali ttf2woff2 meskipun belum diterbitkan selama lebih dari setahun.

Saya memiliki ini dengan couchbase juga

edit: tampaknya diperbaiki di 0.23.2

Itu masih terjadi pada saya pada 0.23.2 ( argon2 dan node-sass dapat dibangun kembali setiap kali saya menambahkan / menghapus beberapa paket yang tidak terkait seperti moment yang tidak memiliki ketergantungan)

OS: Windows 10
Node: 7.9.0
Benang: 0.23.2

Untuk menambahkan lebih banyak warna, persepsi saya tentang hal ini yang terjadi pada yarn add <some-package> jauh lebih besar daripada kenyataan karena banyak kasus bagi saya sebenarnya dipicu oleh penggabungan dengan yarn remove <unrelated-package> segera sebelumnya karena force: true di baris ini .

Tentunya nyaman untuk menggunakan kembali logika install di remove untuk menghasilkan lockfile, tetapi alangkah baiknya jika itu tidak datang dengan semua bagasi dari instalasi paksa :)

Bagi saya ini mulai terjadi lagi ketika saya meningkatkan ke 0.23.x. Saya kembali ke 0.21.3 dan tidak lagi membangun setiap waktu. Ini juga menyebabkan masalah ini di mana IP saya diblokir oleh unicode.org setelah meningkatkan beberapa paket berturut-turut https://github.com/dodo/node-unicodetable/issues/16

Sementara 0.21.3 tidak membangun kembali semua paket saat menambahkan paket baru, ia membangun kembali semua paket saat dihapus. Dan tampaknya benang tidak menganggapnya gagal jika pembangunan kembali gagal.

Bagi saya, menurunkan ke 0.21.3 tidak membantu. bs-platform dibangun kembali pada setiap penambahan / penghapusan.

Melihat ini di macOS dengan Benang 0.23.4. Membangun kembali sqlite3 setiap kali saya menjalankan 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.

Melihat masalah ini dengan Ubuntu 16.04LTS, dengan benang terbaru v0.24.6, dengan node 8.1.2

Saya melihat gdal , node-sass membangun kembali setiap kali saya menambahkan modul, ini menyebabkan penambahan benang membutuhkan waktu lebih lama untuk dijalankan daripada yang diperlukan.

Saya melihat ini juga, sangat mengganggu pada Raspberry Pi Zero W di mana paket pembangunan (seperti bleno) dapat memakan waktu beberapa menit.

Masih melihat ini dengan Yarn v0.27.5 dan uws . Setiap kali sesuatu dalam paket saya berubah, uws dibangun kembali.

Satu-satunya hal menarik yang dapat saya lihat tentang uws adalah ia tidak memiliki field dependensi di package.json .

Ini menjadi cukup membuat saya frustrasi selama beberapa hari terakhir. Saya telah menginstal windows-build-tools secara global pada satu tahap (hanya perlu membangun dirinya sendiri sekali untuk menyiapkan lingkungan dev Windows untuk paket asli) yang terus membangun ulang dirinya sendiri setiap kali saya menambahkan paket. Seperti yang dapat Anda bayangkan, itu memakan waktu cukup lama dan saya akhirnya menyadari bahwa saya tidak perlu menginstalnya lagi dan menghapusnya.

Sekarang tampaknya node-sass terus ingin membangun kembali pada proyeksi lain saat menambahkan paket.

Perilaku ini terjadi pada yarn add dan yarn remove untuk saya. Tentunya tidak diperlukan rekondisi untuk langkah-langkah ini karena paket asli hanya dibuat satu kali sesuai versi Node?

Edit: Menggunakan Node v8.2.1 dan Yarn v0.27.5 pada Windows 10.

Saya tidak dapat menghitung berapa kali uws dibangun kembali untuk saya :) Perhatikan bahwa uws
memiliki nol dependensi dan bahkan bidang di package.json hilang

Pada hari Sen, 31 Juli 2017, pukul 22.50 Paul Myburgh [email protected]
menulis:

Ini menjadi cukup membuat saya frustrasi selama beberapa hari terakhir. Saya punya
windows-build-tools diinstal secara global pada satu tahap (hanya perlu
membangun dirinya sendiri sekali untuk menyiapkan lingkungan dev Windows untuk native
paket) yang terus membangun kembali sendiri setiap kali saya menambahkan paket. Sebagai
Anda dapat membayangkan itu memakan waktu cukup lama dan saya akhirnya menyadari bahwa saya tidak melakukannya
perlu dipasang lagi dan hapus.

Sekarang tampaknya node-sass terus ingin membangun kembali pada proyeksi lain
saat menambahkan paket.

Perilaku ini terjadi pada tambah benang dan lepas benang untuk saya. Pasti tidak
membangun kembali diperlukan untuk langkah-langkah ini karena paket asli hanya dibuat
sekali sesuai versi Node?

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-319192291 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AADWlgSNhi-V9-yGWsWHBDFYdyJW8Arjks5sTj4UgaJpZM4KVN87
.

Saya menggunakan 0.27.5 dan terus melihat perilaku ini dengan bs-platform .

Ini cukup membuat frustrasi, ditto di sini dengan bs-platform .

Rasa berhak yang bagus di sana… Bagaimana dengan Tim Humas?

Pada Sel, 22 Agustus 2017, 10:44 Tim Shnaider [email protected]
menulis:

FFS bisakah ini diperbaiki.
Setidaknya berikan opsi baris perintah atau pengaturan env untuk menonaktifkannya.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-323960245 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AADWltQedG4owTlcC8koC4RL-vTiCE0Hks5sapTbgaJpZM4KVN87
.

Sejauh ini tampaknya tidak disebutkan, tetapi saya juga dapat mereproduksi bug ini dengan yarn global list .

Langkah-langkah untuk mereproduksi:

1. Gunakan global env:: peringatan: jalankan ini hanya jika Anda tahu apa yang Anda lakukan

   rm -rf ~/.config/yarn/
   

2. Tambahkan paket bermasalah (_yaitu 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.
   

3. Jalankan yarn global list dan lihat beberapa paket asli sedang dikompilasi ulang

4. Ulangi sebanyak yang Anda inginkan, yarn global list akan selalu mengkompilasi ulang paket asli tersebut
5. 😭

Saya harap ini membantu.

ℹ️ MacOS 10.12.6 dengan Benang 0.27.5 diinstal melalui Homebrew.

Hak tersebut tidak diperlukan, tetapi saya dapat memahami rasa frustrasinya. Ini membuang banyak waktu bagi banyak orang (penginstalan ulang yang lama bertambah seiring waktu dan aliran jeda). Tentu, Anda bisa mengatakan "buat permintaan tarik" - dan itu adil. Tetapi ini akan menjadi proses pembelajaran selain mengubah secara potensial hanya beberapa baris kode ... Yang kami harapkan adalah orang-orang yang mengetahui seluk beluk proyek ini dapat memprioritaskan masalah ini pada rilis berikutnya karena benar-benar memang tampak agak besar (dan kemungkinan merupakan perbaikan yang mudah? Cegah penginstalan ulang binari jika versi Node mungkin belum berubah).

Sudah hampir setahun sejak pertama kali dilaporkan.

Saya harap saya kedengarannya tidak berhak mengatakan itu ... Saya ingin menambahkan bahwa saya sangat berterima kasih atas proyek ini dan kegunaannya bagi saya. Masalah ini telah menjadi salah satu dari sedikit masalah yang saya alami dengannya.

EDIT: Baru saja melakukan yarn remove untuk paket acak dan itu mencoba dan (kali ini) gagal membangun kembali binari saya. Efek sampingnya adalah binari saya benar-benar hilang sekarang dan tampaknya satu-satunya cara untuk memperbaikinya adalah dengan npm rebuild . Jadi tidak hanya tampaknya masalah ini menyebabkan pembangunan kembali yang tidak perlu - tetapi jika gagal proses itu, tampaknya Anda harus menggunakan kembali ke npm untuk memperbaikinya lagi.

Saya melihat perilaku yang sama seperti @zhangjyr dan @lostpebble. Menjalankan yarn add berfungsi dengan baik tetapi yarn remove menyebabkan paket asli dibangun kembali.

Mac Sierra 10.12.6
Benang 0.27.5

Saya akan mencoba untuk melihat apa yang dapat saya lakukan tentang ini karena ini juga memengaruhi saya. Meski demikian, Yarn tidak terlalu sulit untuk berkontribusi, jadi jika seseorang ingin mengirim PR, silakan mencobanya dan kami akan mencoba mendukung Anda semaksimal mungkin.

Saya tidak akan dapat mengerjakan ini selama beberapa minggu.

Saya melihat ini juga.
Bekerja di situs, dibangun di atas gatsby. Operasi benang APAPUN menyebabkan rekondisi.
Coba buat situs dengan gatsby dan yarning dengannya. Semoga ini membantu

Melihat ini dalam proyek menggunakan gatsby:
benang 1.0.2
simpul 7.10.1
ubuntu 16.04

Masalah ini menjadi sangat serius sekarang. Tidak hanya binari saya yang selalu dibuat ulang. Tetapi sering terjadi bahwa binari saya dihapus sepenuhnya setelah yarn add atau yarn install (setelah mengubah nomor versi paket di package.json untuk memperbarui / mengembalikan modul). Dan tidak peduli berapa banyak saya menjalankan yarn install atau yarn install --check-files sesudahnya, binari itu hilang begitu saja dan tidak pernah kembali. Satu-satunya cara untuk mendapatkannya kembali adalah dengan npm rebuild .

Ini mulai terasa seperti benang tidak memiliki pengetahuan sama sekali tentang keadaan paket asli. Apakah mereka sudah terpasang / dibangun, atau jika tidak dipasang / dibangun dengan benar.

Apakah mungkin sudah ada kemajuan dalam hal ini?

Saya pikir penambahan bidang artifacts ke file integritas benang oleh @arcanis akan membantu memperbaiki masalah ini. Belum ada kemajuan tetapi terbuka untuk PR :)

Saya memiliki masalah yang sama dengan bs-platform saat menginstal paket di proyek reasonml saya

Sama ... secara harfiah setiap yarn add akan membangun kembali proyek gyp.

Terjadi di sini juga.
(benang 1.2.1)

Saya melihat ini dengan node-sass .

Terjadi pada saya dengan Cypress misalnya.

node -v
v8.8.1
benang -v
1.2.1

✋ Daripada menulis "Saya juga" tanpa info tambahan, gunakan fitur +1 di Github pada postingan teratas . Setiap kali Anda menulis komentar "saya juga", 35 pelanggan tidak perlu diberi tahu.

+1

Silakan klik Subscribe jika Anda ingin menerima pembaruan. Saya berharap semua orang ingin diberi tahu jika masalah ini telah diselesaikan, tetapi tidak saat orang baru juga menghadapi masalah ini.

@BYK dapatkah Anda mengunci utas, dan membuatnya tersedia hanya untuk pemilik.

Saat ini saya sedang menyelidiki masalah ini dan mencoba meringkasnya menjadi kasus uji minimum yang dapat direproduksi. Paket "hebat" untuk mendemonstrasikan masalah ini adalah htmlstrip-native - perlu waktu beberapa menit untuk dikompilasi sehingga Anda tidak dapat melewatkannya.

Saya ingin orang lain mencoba package.json dalam folder kosong:

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

Coba jalankan perintah ini:

yarn
yarn upgrade [email protected]

Di mesin saya, dengan benang terbaru 1.2.1, perintah upgrade menghasilkan pembangunan kembali htmlstrip-native yang membutuhkan waktu selamanya. Benang tidak boleh membangun kembali ini karena memutakhirkan left-pad tidak berpengaruh pada htmlstrip-native atau ketergantungannya.

Sekarang coba npm :

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

Di komputer saya, perintah kedua (dengan benar) tidak menghasilkan rekondisi baru htmlstrip-native .

EDIT : Dari membaca ulang semua posting di atas, sepertinya kasus ini tidak akan mengejutkan siapa pun - kebanyakan orang, termasuk saya, menemukan bahwa hanya meminta benang untuk melakukan _anything_ menghasilkan pembangunan kembali. Saya rasa ini bukan masalah yang lebih besar di komunitas karena kebanyakan orang tidak menggunakan paket asli yang membutuhkan waktu lama untuk membuatnya - jadi mereka juga tidak memiliki langkah membangun kembali atau selesai begitu cepat, siapa peduli.

Oke, jadi setelah banyak debugging, tampaknya perilaku ini disengaja. Menelusuri kode, tampaknya, misalnya, yarn upgrade [email protected] menghasilkan langkah-langkah berikut:

1) modul upgrade dipanggil, yang menjalankan operasi new Add() untuk left-pad .
2) Add.init() panggilan ke superclass-nya, Install.init()
3) Install.init() mengantri langkah rebuildingPackages
4) Dalam PackageInstallScripts.init() itu hanya mengumpulkan paket _all_ dan menambahkannya ke workQueue untuk dibangun kembali.
5) PackageInstallScripts kemudian menemukan bahwa ada perintah instal untuk htmlstrip-native dan jalankan saja - ini adalah pembangunan kembali asli super lambat yang kita semua lihat.

Dari semua yang saya lihat sejauh ini, tampaknya tidak ada logika yang bermaksud untuk menyaring paket yang tidak "perlu" dibangun ulang. Ini hanya membangun kembali semuanya, seperti yang dinyatakan dalam keluaran konsol.

Saya ingin seseorang dari tim Yarn ikut serta - jika perilaku ini benar-benar disengaja, saya sarankan untuk menutup masalah ini!

Untuk situasi saya pribadi, saya hanya akan menukar ketergantungan htmlstrip-native karena tidak ada alasan perlu waktu beberapa menit untuk membangun (seperti, beberapa file kecil .c ). Departemen asal saya yang lain membangun dengan cepat, jadi bukan masalah besar jika itu terjadi setiap saat.

Kedengarannya seperti efek samping desain yang tidak disengaja, tetapi mungkin seseorang di @ yarnpkg / core dapat mengomentarinya. Saya tidak berpikir ini dimaksudkan untuk membangun kembali paket yang tidak perlu dibangun kembali.

Ini tidak disengaja, mungkin lebih mudah untuk diterapkan seperti itu.
Ada komentar di atas dari BYK yang mengatakan masalah ini sedang mencari PR:
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

Tentu saja paket native-heavy tidak cukup umum untuk ditampilkan sebagai prioritas tertinggi untuk Yarn, namun Yarn memiliki kemampuan untuk tidak membangun ulang paket pada setiap pemasangan.
Ini sepertinya bug yang harus segera diperbaiki, kirim PR.
Mungkin ada peringatan karena Yarn tidak dapat mengetahui dengan pasti apakah paket yang dibangun mungkin telah rusak, itulah sebabnya mengapa sekarang dengan bersemangat menjalankan ulang skrip instalasi.

Ada garpu Benang yang digunakan oleh tim di belakang Reason https://github.com/esy-ocaml/esy-install yang menangani banyak masalah kompilasi asli karena dependensi Reason / Ocaml memerlukan kompilasi yang berat.
Saat pendekatan tersebut semakin matang, saya berharap akan memungkinkan untuk menggabungkan perubahan di hulu.

Jadi pada dasarnya, paket asli dibuat ulang karena:

1) Bendera force=true telah disetel, atau
2) Paket telah ditandai fresh=true .

Sepertinya dengan beberapa perintah (seperti upgrade dan remove ), tanda force disetel ke true "untuk berjaga-jaga". Bendera ini menjanjikan untuk "membangun kembali semua paket terlepas dari apakah mereka telah berubah" sehingga tidak masuk akal untuk menambahkan beberapa kode deteksi perubahan karena hal itu akan melanggar janji ini.

Jadi untuk memperbaikinya, sepertinya kita perlu menantang asumsi berbagai tempat dalam kode yang menyetel force=true .

Yang pertama saya lacak terjadi saat menjalankan yarn upgrade whatever . Itu diperkenalkan dalam komit ini sebagai bagian dari # 2780 oleh @juanca. Catatan komit mengatakan:

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

Mungkin @juanca atau seseorang yang lebih akrab dengan sejarah benang bisa ikut campur dengan masalah yang ingin diselesaikan ini?

@nfarina terima kasih, itu membawa kejelasan. Untuk peningkatan, mungkin kami benar-benar ingin membuat paket asli secara paksa (jika sedang ditingkatkan). Tetapi untuk penginstalan (yarn add), menurut saya kami secara sah perlu menantang, seperti yang Anda katakan, asumsi yang membuat paket asli yang sudah terinstal dibangun kembali ketika sesuatu yang lain diinstal.

Saya kira force flag disetel sehingga resolver Yarn tidak melewatkan ketergantungan yang ada karena versi lama ada di yarn.lock.

Saya pikir itu adalah solusi cepat untuk membuat pekerjaan upgrade.
Cara yang tepat adalah dengan mengoper bendera lain yang hanya mempengaruhi resolusi paket yang ditentukan dan tidak akan sehebat force .
Kirim PR :)

Mungkin @juanca atau seseorang yang lebih akrab dengan sejarah benang bisa ikut campur dengan masalah yang ingin diselesaikan ini?

Benar, saya bekerja hanya dengan Add API - tidak (melakukan?) Saat menambahkan paket yang sudah ada.

Saya juga merekomendasikan menggunakan teknik yang lebih baik dalam mengontrol aliran prosedural.

Saya menggunakan benang pada raspberry pi zero saya dalam proyek yang memiliki ketergantungan ke node-opencv. Setiap kali saya menambah / menghapus / memperbarui paket yang tidak terkait, saya harus menunggu 35 menit untuk membangun kembali.

@ Torsten85 , saya juga menggunakannya di pi, ya pembangunan kembali yang tidak perlu adalah sesuatu yang perlu kita tangani.
Dapatkah Anda menyediakan skrip repro untuk pembangunan kembali Anda?

sama di sini, di lubuntu 17.10, ketika saya menggunakan benang, berkembang dengan https://github.com/mui-org/material-ui

setiap yarn add/remove (-D) <pkg> membangun kembali semuanya, seperti instalasi baru, membutuhkan lebih dari 1 menit

Apakah ini cara npm menanganinya juga? Jika tidak, apakah itu solusi yang mungkin untuk beralih sementara?

juga terjadi di sini

• simpul 9.2.0
• benang 1.4.0

setiap kali saya menambahkan beberapa ketergantungan, modul seperti bcrypt atau couchbase dibangun kembali setiap saat

Halo semuanya, saya sedang mengerjakan peretasan kecil https://github.com/yarnpkg/yarn/pull/5314.
Idenya adalah untuk menyimpan paket yang dibangun ke dalam cache offline untuk menghindari menjalankan skrip instalasi sepanjang waktu.

Jadi jika Anda menggunakan cermin luring dan menjalankan yarn add node-sass :

1. benang akan membangun dan memasang node-sass seperti biasa,
2. setelah menginstal script dijalankan maka akan menghasilkan node-sass-v4.7.2-darwin-x64-57.tgz dari dimodifikasi node_modules/node-sass folder
3. Lain kali Anda menjalankan yarn install pada platform yang sama itu hanya akan membongkar node-sass-v4.7.2-darwin-x64-57.tgz alih-alih yang asli dan tidak akan menjalankan skrip instalasi

Ini tidak akan berfungsi untuk setiap kasus tetapi ini bisa menjadi solusi untuk sistem CI offline di mana Anda tidak ingin paket menjangkau kami ke internet dan menjalankan skrip pemasangan yang sama setiap saat.

Saya mencoba memasang skrip ketikan sebagai paket global, dan benang menghabiskan seluruh waktu membangun kembali barang-barang alih-alih memasang apa yang sebenarnya saya butuhkan sekarang.

Saya pindah ke benang berpikir itu lebih cepat, dan lebih baik. Saya menghapus semua jejak npm (kecuali yang disertakan dengan instalasi node); dan menginstal ulang semua paket global ke benang.

Yarn sekarang menguji kesabaran saya dengan membuat saya menunggu selama 1-15 menit untuk instalasi paket sederhana. Yarn harus cukup pintar untuk menginstal apa yang diminta terlebih dahulu sebelum membangun kembali barang lain kecuali paket yang diminta secara eksplisit bergantung pada paket asli mana pun yang memerlukan pembangunan kembali.

Lingkungan Hidup:

• Node: 9.4.0
• Benang (global): 1.3.2
• macOS Sierra: 10.12.6
• Macbook pro 15 inci
  
  
  
  • Memori: 16 GB
  
  
  • CPU: 2GHz - Intel Core i7
  
  
  • Penyimpanan: magentic (banyak ruang kosong)
  
  
  • Aplikasi yang berjalan saat instalasi: Firefox (6 tab), Mail.app, dan iTerm (dengan 2 tab)
  
  

Log

Mengambil Paket membutuhkan banyak waktu

benang skrip upgrade global
benang global v1.3.2
[1/4] 🔍 Menyelesaikan paket ...
[2/4] 🚚 Mengambil paket ...
[############################################## ############ -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

Menghubungkan Dependensi macet tanpa kemajuan apa pun selama beberapa menit

benang skrip upgrade global
benang global v1.3.2
[1/4] 🔍 Menyelesaikan paket ...
[2/4] 🚚 Mengambil paket ...
[3/4] 🔗 Menautkan dependensi ...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

Membangun kembali semua paket - membutuhkan banyak waktu

benang skrip upgrade global
benang global v1.3.2
[1/4] 🔍 Menyelesaikan paket ...
[2/4] 🚚 Mengambil paket ...
[3/4] 🔗 Menautkan dependensi ...
[4/4] 📃 Membangun kembali semua paket ...
[17/12] ⠐ websocket
[17/2] ⠐ expresso: memeriksa opsi gcc untuk menerima ISO C99 ...
[8/17] ⠐ serialport: menggunakan [email protected] | darwin | x64
[17/6] ⠐ sekarang:> Untuk kode sumbernya, lihat: https://github.com/zeit/now-cli

benang skrip upgrade global
benang global v1.3.2
[1/4] 🔍 Menyelesaikan paket ...
[2/4] 🚚 Mengambil paket ...
[3/4] 🔗 Menautkan dependensi ...
[13/17] ⠈ tanpa server
[13/17] ⠂ tanpa server
[14/17] ⠠ solgraf
[14/17] ⠁ solgraf
[14/17] ⡀ solgraf
[- / 17] ⠈ menunggu ...
[- / 17] ⠄ menunggu ...
[- / 17] ⠠ menunggu ...
[- / 17] ⠈ menunggu ...
[- / 17] ⠄ menunggu ...
[- / 17] ⢀ menunggu ...
[- / 17] ⠈ menunggu ...

Saya terus menunggu :-)

efek samping lain adalah bahwa pustaka yang mengunduh dan cache precompiles juga dihapus dan harus diunduh lagi: yaitu nwjs-builder-phoenix cache dari build-target sdks

1. Paket asli selalu dibuat ulang saat memperbarui versi paket yang merupakan paket non-asli.

Apakah benang menyimpan biner ke global seperti npm?

Ini mulai membuat saya sedikit frustrasi karena harus membangun kembali nwjs di setiap instalasi sederhana. Tidak masuk akal

saya melihat ini juga. uws dibangun kembali setiap kali saya melakukan operasi tambah / hapus. benang v1.3.2

Hai @bestander. Kami telah mencoba # 5314 pada monorepo perusahaan kami, namun tidak berpengaruh pada penghentian pembangunan kembali beberapa dependensi untuk kami. Kami telah mengaktifkan yarn-offline-mirror dan pack-built-packages di .yarnrc seperti yang ditunjukkan dalam tes tambahan.

Intinya adalah menjalankan yarn selalu membutuhkan waktu sekitar 40-50 detik bagi kita, bahkan jika perintah yang kita jalankan secara langsung sebelumnya adalah yarn juga.

@ bazyli-brzoska, saya telah mengubah panji menjadi lebih eksplisit dan lupa memperbarui deskripsi.
Bisakah Anda mencoba dengan flag experimental-pack-script-packages-in-mirror set sebagai "true"?

Apakah ada kemajuan dalam hal ini? Saya melihat pull request sudah digabungkan dan ada di rilis terbaru 1.5.1. Saya menggunakan 1.5.1 dan tidak ada yang berubah untuk saya. Namun demikian, saya mempertimbangkan untuk kembali ke npm, karena menunggu 322.70s atau 282.69s atau bahkan 683.41s (ini benar-benar tiga yarn add s terakhir saya) untuk memasang plugin rollup kecil atau lodash atau well, hampir semuanya, tidak masuk akal.

Akan luar biasa jika peringatan utama seperti ini ada di README.md Anda. Pengguna memasang benang karena diduga "lebih cepat" dan melakukan transisi ini dari npm ke benang bukanlah langkah kecil, jadi alangkah baiknya jika ada peringatan sebelumnya untuk pengembang, sehingga mereka dapat memikirkannya sekali lagi, sebelum mengonversi skrip mereka, mencemari global mereka dan mempelajari benang cli.

Saya pikir ini hanya masalah dengan mesin 32 bit lama saya, tetapi setelah melihatnya untuk ke-237 kalinya, saya mencarinya di Google dan oh, benang tidak lebih cepat. Bagus.

Maaf karena mungkin bersikap jahat, tetapi saya pikir Anda membuat Anda frustrasi.

Kami menerima kontribusi.

Karena itu, sesuatu yang perlu diingat terkait paket yang dapat dibangun kembali ketika mereka tidak "perlu": langkah-langkah build dijalankan setelah dependensi diinstal. Artinya, skrip build diizinkan untuk menggunakan dependensi tersebut. Artinya jika dependensi ini berubah karena alasan apa pun (yang mungkin terjadi 'secara acak', misalnya jika kita mengoptimalkan dua versi paket yang kompatibel menjadi satu), maka kita sebenarnya perlu menjalankan kembali langkah - langkah build

Jadi, ini bukan masalah yang mudah. Setidaknya sebagian dari masalah berasal dari desain package.json itu sendiri. Ceritakan tentang frustrasi 🙂

@arcanis Saya tidak mendapatkan bagian ini:

bahkan jika dependensi tersebut tidak benar-benar digunakan selama build (karena bagaimana kita bisa tahu?).

Saya berpikir bahwa desain YARN adalah untuk mempertahankan versi + dependensi statis (kunci-benang) dan karenanya tidak akan ada "pembaruan" acak.
Meskipun paket json memberikan pohon penuh, jadi mengapa Anda mengatakan "bagaimana kami bisa tahu"? Setelah hierarki terselesaikan, sangat mudah untuk mengatakan, jika ada dependensi (bahkan yang level dalam) untuk membangun X berubah atau tidak.

Misalkan saya memiliki ketergantungan foo yang bergantung pada babel-core dan left-pad@^1.0.0 , dan bahwa ketergantungan foo memiliki skrip build yang menjalankan babel pada file indeksnya .

Setelah menjalankan yarn add foo di folder proyek saya, saya akhirnya memiliki [email protected] di node_modules, bukan? Sekarang katakanlah versi kiri-pad baru dirilis ( 1.1.0 ), dan saya ingin menggunakannya dalam proyek saya. Saya akan menjalankan yarn add left-pad , yang kemudian akan menjadi latest , yaitu 1.1.0 .

Sekarang apa yang bisa terjadi adalah bahwa Yarn akan "melihat" bahwa ada dua salinan pad kiri di pohon, dan juga akan melihat bahwa mereka dapat dioptimalkan: bagaimanapun juga, foo tergantung pada left-pad@^1.0.0 , jadi 1.1.0 juga kompatibel. Jadi itu akan menghapus versi sebelumnya, dan hanya menggunakan 1.1.0 . Karena ketergantungan berubah, kita perlu menjalankan skrip build lagi karena Yarn tidak memiliki cara untuk mengetahui bahwa left-pad adalah dependensi waktu proses daripada dependensi waktu-build .

Sekarang Anda mungkin bertanya "tetapi mengapa tidak melewatkan pembangunan kembali ketika dependensi transitif berubah?". Jawabannya adalah bahwa beberapa paket (khususnya paket native) memiliki dependensi yang secara radikal memengaruhi cara pembuatannya. Ketika itu terjadi, kami benar-benar ingin membangun kembali paket-paket itu, atau kami akan berakhir dengan artefak yang tidak kompatibel.

@arcanis , saya rasa Anda salah paham tentang masalah ini. Masalahnya di sini adalah bahwa paket asli ini dibuat ulang _setiap_ kali, bahkan ketika yarn dijalankan dua kali (atau lebih) secara berurutan. itu _tidak ada yang harus dilakukan dengan pembaruan dependensi - itu _always_ membangun kembali.

@Spongman Saya setuju dengan komentar terbaru Anda. Tapi seperti yang disebutkan dengan benar oleh @Spongman , pembangunan kembali terjadi setiap saat . Bahkan jika Anda melakukan hanya yarn && yarn - Anda mendapatkan dua pembangunan kembali penuh , meskipun kenyataannya tidak ada yang berubah dalam struktur ketergantungan.

Saya mencoba menjalankan yarn add leveldown bcrypt && yarn && yarn seperti di OP dan hanya mendapat satu build: / Apakah Anda memiliki perintah yang dapat saya gunakan untuk merepro perilaku ini?

Anda dapat mencoba misalnya:

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)

(ini di bawah Ubuntu 14 LTS)

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

yarn & yarn 

Tidak menyebabkan dua rekondisi, tetapi contoh dengan socket.io, menambahkan react, menghapus react menyebabkan dua rekonstruksi

Saya mencoba contoh socket.io dengan benang v1.5.1 dan tidak mendapatkan rekondisi saat menggunakan fitur baru untuk menyimpan cache bawaan. Untuk melakukan itu, Anda perlu menggunakan cache offline. Dalam ~/.yarnrc saya, saya memiliki:

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

Ketika saya mencoba sebagai pengguna lain tanpa konfigurasi itu, ia membangun kembali setiap saat.

Ya, tidak ada rekondisi sekarang saat menambahkan opsi ini.
Tetapi jika hanya experimental-pack-script-packages-in-mirror true , itu masih membangun kembali.
Mengapa tidak menyetel yarn-offline-mirror ke jalur default seperti "~ / .yarn / cache".

Masih eksperimental, tapi ini saran yang menarik (cc @bestander). Saya kira masalah yang saya hadapi dengan ini adalah bahwa saya pribadi tidak menyukai gagasan untuk mengaktifkan sesuatu tanpa persetujuan eksplisit dari pengguna. Ini juga memiliki implikasi lain: apa artinya memiliki yarn-offline-mirror disetel menjadi false , dan experimental-pack-script-packages-in-mirror menjadi true ? Haruskah experimental-pack-script-packages-in-mirror menimpa pengaturan yarn-offline-mirror ? Imo agak membingungkan.

Karena itu, bug untuk membangun kembali uws saat menambahkan left-pad memang agak mengganggu, dan hanya pengaturan experimental-pack-script-packages-in-mirror adalah solusinya. Saya tidak yakin saya akan memiliki bandwidth untuk melihat ini pada minggu depan atau lebih, tetapi jika seseorang tertarik untuk melakukan perbaikan, itu akan sangat berdampak.

@arcanis Terima kasih atas tanggapan yang baik. Frustrasi datang dari cara benang disajikan. Saat ini tidak "cepat", pasti tidak lebih cepat dari npm dan agak tidak dapat digunakan dalam proyek dunia nyata. Imho, harus ada info tentang ini atau bahkan solusi oleh @skomorokh di file README.md Anda hingga ini diperbaiki. Atau hapus saja "puasa" dari deskripsi Anda.

Saya akan merasakan frustrasi yang sama, jika readme dari angularjs repo menyatakan bahwa ini adalah kerangka yang ringan. Hanya saja tidak.

Selalu berulang untuk mengunduh file biner setelah yarn-offline-mirror config.

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

Akan mencoba men-debug ini sedikit hari ini. Saya pikir sebenarnya mungkin sesederhana PackageInstallScripts tidak memeriksa pkg.fresh hanya untuk membangun kembali paket yang baru diinstal. Alih-alih, sepertinya itu hanya mengulang semuanya.

Setelah beberapa mengotak-atik, saya mulai berpikir bahwa kita membangun kembali hal-hal sepanjang waktu jika seseorang rm -rf node_modules atau modul dihapus dari sana.

Kami memiliki daftar artefak build yang terdeteksi di file .yarn-integrity , jadi menurut saya, pembuatan ulang hanya akan terjadi jika fresh package || module destination dir does not exist || any file in integrity artifacts does not exist || --force flag was passed

Jadi ini sedikit lebih terlibat dari yang saya kira.

Saya baru saja yarn add ed moment , sebuah paket ketergantungan nol, ke aplikasi react terbaru saya, dibutuhkan 377.97s .

Melakukannya lagi tepat setelah itu, dibutuhkan 389.63s dan membangun kembali binari lagi.

Sekadar perbandingan, saya kemudian menghapus node_modules dan memasukkan npm install :
added 1751 packages and updated 124 packages in 360.595s

Beralih kembali ke npm sekarang.

Oke, beberapa info lagi untuk semua mata tentang masalah ini ... Saya telah mengotak-atik hal ini selama satu setengah hari sekarang dan akhirnya menyadari beberapa hal.

Pertama, sebagian besar masalah pembangunan kembali ini telah diperbaiki. Sudah ada kode di PackageInstallScripts yang hanya menjalankan kembali skrip instalasi untuk sebuah paket yang ditandai "segar" :

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

Jadi misalnya jika Anda menggunakan node-sass :

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

Juga yarn install s berturut-turut tidak dibangun kembali.

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

... tapi tentu saja ada beberapa pengecualian ...

Pada yarn remove flag force disetel (untuk memperbaiki beberapa bug lain yang saya asumsikan, tetapi sudah seperti itu selama> 2 tahun) sehingga pembangunan ulang selalu terjadi.

Namun, ini bisa dibilang "benar" karena itu juga yang dilakukan 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

Anda dapat melihat bahwa pada uninstall dari left-pad , npm menjalankan skrip install dan postinstall untuk node-sass .

Paket uws (yang digunakan oleh beberapa paket lain, seperti socket.io , browser-sync , dll ...

sesuatu selama proses instalnya mengubah salah satu file (ukuran dan stempel waktu berbeda).

~/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

benang melihat file yang telah "berubah" dibandingkan dengan cache sehingga menandai paket "segar" untuk instalasi ulang

Ini kemudian memicu logika di atas yang menjalankan kembali skrip instal karena "baru". Yarn mencoba untuk membantu dan "memperbaiki" file yang salah, tetapi tentu saja Yarn tidak tahu bahwa file tersebut berubah karena skrip instal. Kami mungkin harus menyelidiki beberapa cara untuk memperbaikinya, tetapi ada juga pembicaraan tentang mengubah cara file-file ini dibandingkan (berhenti menjalankan stat pada setiap file), jadi mungkin bisa diselesaikan dengan pengerjaan ulang itu.

Mudah-mudahan itu menjelaskan beberapa kasus di sini di mana beberapa orang mengatakan itu berhasil dan yang lain mengatakan tidak.

Terima kasih telah menyelam lebih dalam di sana, @ rally25rs.

1. Re: menggunakan force dalam perintah hapus.
   Itu jelas merupakan perbaikan bug sudut cepat yang mencapai kebenaran dengan pendekatan nuklir IIRC https://github.com/yarnpkg/yarn/pull/323.
   Seharusnya tidak sulit untuk menghapus force dan mengatasi masalah tersebut.

2. node_modules/uws/uws_darwin_57.node : file ini harus berada di bidang artifacts .yarn-integrity dan kemudian uws tidak boleh ditandai sebagai tidak segar selama penautan.
   Mungkin ada yang salah di sini

@bestander ah poin yang bagus di 2. Saya akan mencoba untuk melihat apakah ada cara yang waras untuk mengerjakannya dengan memeriksa.

@stereokai Dalam komentar saya di atas, saya mencatat bahwa npm juga membangun kembali paket saat uninstall / remove, jadi kasus itu bisa dibilang "benar" jika Anda menganggap perilaku npm sebagai standar.

@ rally25rs Terima kasih telah menunjukkannya :)

Namun, saya menganggap perilaku ini buggy terlepas dari pengelola paketnya. Sulit untuk memahami mengapa perilaku semacam ini bahkan diperlukan untuk pengoperasian yang benar. OS Anda tidak menginstal ulang program lokal saat Anda menambahkan / menghapus program lain, karena aplikasinya sudah ada. Saya tidak akan mengharapkan hal lain dari manajer ketergantungan statis, nahmean?

@stereokai Saya agak setuju, itulah mengapa saya menggunakan frase "bisa dibilang benar" 😆
OS Anda juga tidak mengubah tempat aplikasi lain diinstal saat Anda menghapus aplikasi yang tidak terkait.

Asumsikan Anda memiliki beberapa pohon ketergantungan seperti:

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

Jika Anda menginstal ini, maka itu akan membentuk struktur direktori yang sama di bawah node_modules , karena tidak dapat mengangkat depB ke root.

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

Tetapi dari kalian yarn remove depB maka struktur dep yang baru adalah:

myProj
  |- depA v1
       |-depB v2

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

jadi direktori sebenarnya tempat depB v2 diinstal dapat berubah setiap kali sebuah paket ditambahkan atau dihapus. Direktori tersebut tidak hanya disalin dari satu lokasi ke lokasi lain. Yang lama dihapus dan yang baru disalin dari cache ke tujuan baru, yang berarti artefak bangunan yang ada di node_modules/depA/node_modules/depB tidak akan ada lagi, dan perlu dibuat ulang di node_modules/depB .

Demikian juga, yarn add [email protected] akan mengubah jalur di mana depB v2 diinstal (sebenarnya saya harus menguji bahwa PR saya untuk tidak membangun kembali pada yarn add benar-benar berfungsi dalam kasus ini)

Saya menduga itulah sebabnya paket-paket ini dibangun kembali setiap saat.

Perubahan sebenarnya terjadi dalam komit ini: https://github.com/yarnpkg/yarn/commit/5300b482c851e2578ac1f3aa4908be4d0289dca8
kembali pada tahun 2016. File tersebut bernama uninstall.js pada saat itu, tetapi force: true telah ditambahkan ke bendera yang diteruskan ke install . Sepertinya tidak ada sesuatu yang spesifik dalam komentar komit untuk mengindikasikan _why_.

Akan sangat bagus jika ada cara untuk menghindari pembangunan kembali setidaknya dalam _some_ kasus.

Siapapun dipersilakan untuk mengerjakan PR. 😸Seperti yang saya tunjukkan di atas, pembangunan kembali sudah tidak terjadi pada yarn install dan yarn add (dalam banyak kasus). Saya memiliki # 5470 terbuka yang seharusnya menghilangkan pembangunan kembali yang tidak perlu untuk yarn add ketika Anda memiliki uws dalam ketergantungan Anda (atau paket lain yang mengubah file itu sendiri selama instalasi). Kasus yang tersisa yang saya tahu adalah yarn remove .

Setelah membaca sebagian besar utas ini, saya tidak mengerti apa yang terjadi di sini.

Saya memiliki beberapa paket asli yang sedang dibangun kembali setiap kali saya menggunakan yarn add untuk modul lain (tidak terkait). Dibutuhkan sekitar 20 menit dari beban yang sangat tinggi pada CPU di laptop saya. Saya tidak bisa bekerja seperti itu.

Ternyata, dari utas ini, sudah menjadi masalah selama 19 bulan.

Apakah ini bug? Apakah itu sedang dikerjakan? Apakah ada solusinya? Haruskah saya beralih kembali ke npm?

Haruskah saya beralih kembali ke npm?

ya, sampai # 5470 dirilis.

@viral

Ternyata, dari utas ini, sudah menjadi masalah selama 19 bulan.

Itu sebenarnya sudah diperbaiki (kebanyakan) sejak lama. Utas ini tetap terbuka untuk satu kasus tepi yang saya temukan beberapa minggu yang lalu di mana benang akan membangun kembali paket jika paket itu mengubah salah satu file itu (menurutnya file tersebut salah dibandingkan dengan apa yang ada di unduhan asli, jadi ingin memperbaikinya Itu). Dan untuk beberapa diskusi terbuka tentang jika remove dan upgrade harus melakukan pembangunan kembali (itu dilakukan di npm, tetapi mungkin tidak seharusnya)

Apakah ini bug?

Mungkin. Paket mana yang sedang dibangun kembali? Satu-satunya yang saya tahu yang menjadi masalah konstan adalah uws , jadi mengetahui lebih banyak akan membantu.

Apakah itu sedang dikerjakan?

Kasus spesifik yang saya sebutkan di atas diperbaiki di # 5470

Apakah ada solusinya?

Jika paket yang Anda tambahkan tidak memiliki skrip penginstalan, Anda dapat menggunakan --ignore-scripts

Atau, Anda dapat memeriksa cabang dari PR di atas dan menggunakannya.

Dibutuhkan sekitar 20 menit

Wow. Saya penasaran paket apa itu.

Terimakasih telah menjawab.

Paket noise-search , level-rocksdb dan jq dikompilasi ulang setiap kali saya menambahkan paket yang tidak berhubungan dengan yarn add . Laptop saya agak tua, jadi butuh waktu yang sangat lama untuk mengkompilasinya di waktu yang sama.

Saya menggunakan Yarn 1.5.1 dan node 9.8.0.

@vibl yeesh, noise-search jelas merupakan penyebab di balik pembuatan panjang ...

~/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.

lebih dari 7 menit di MacbookPro 😢

Bagaimanapun, saya menginstal noise-search lalu menjalankan yarn add left-pad dengan kode dari # 5470 dan itu _not_ menyebabkan pembangunan kembali, jadi saya pikir Anda sebaiknya pergi setelah kami menggabungkannya 👍

Terima kasih :-)

Haruskah saya memeriksa kembali Yarn dalam beberapa hari, beberapa minggu, atau beberapa bulan?

Saya baru saja menemukan bahwa bug ini, dengan proyek yang sama persis pada laptop yang sama (dual boot), tidak terjadi pada Windows 10. Tetapi ada di tiga versi Debian terbaru, Ubuntu, Arch Linux dan Fedora. Aneh. Belum mencoba MacOS, tetapi tampaknya beberapa orang juga mengalami masalah di sana.

@vibl Saya tidak yakin kapan rilis kami berikutnya (saya tidak terlibat dalam perencanaan itu)

@ nnmrts ya saya menemukan bahwa itu adalah hal khusus OS. Dari komentar saya di # 5470:

di linux dengan node 8, ketika file disalin dari cache ke node_modules, stempel waktu diperbarui. benang memutuskan file berbeda dan menandai referensi baru.
Ini sepertinya hanya terjadi pada linux node 8.
ini karena Node v8.5 memperkenalkan fs.copyFile yang membuat salinan jauh lebih cepat. IIRC yang menyalurkan ke salinan sistem file asli, sehingga akan menjelaskan mengapa ia bekerja secara berbeda di seluruh OS dan hanya di node 8.

@ rally25rs @nnmrts Ini jelas bukan hal khusus MacOS. Juga terjadi pada PC Win10 saya

@stereokai Yah, seluruh masalah ini tidak spesifik. Terkadang paket perlu dibangun kembali dan orang-orang masih menganggapnya sebagai bug dan mempostingnya di sini. Tanpa repo yang solid untuk setiap os, kita tidak bisa tahu apa-apa.

Caching modul yang dibangun secara lokal (dari # 5314) dapat membantu ?:

Tambahkan .yarnrc ke proyek Anda dengan yang berikut ini:

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

Setelah penginstalan pertama, modul prebuilt akan tersedia dalam ./<your-offline-mirror-path>/prebuilt . yarn.lock juga diperbarui dengan varian bawaan

Menarik 66a0143a753cd4ade1a0fffee2174890d564c129 terbaru, dan tampaknya berfungsi dengan baik😎

MASIH mengunduh biner berulang kali.

• node v6.13.1
• benang v1.6.0-20180327.1507
• OS: Ubuntu 17.10 Linux 4.13.7-041307-generik
• ~ / .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

Pada Kamis, 29 Maret 2018 pukul 02.30, Andrew Lane [email protected]
menulis:

Caching modul yang dibangun secara lokal (dari # 5314
https://github.com/yarnpkg/yarn/pull/5314 ) dapat membantu ?:

Tambahkan .yarnrc ke proyek Anda dengan yang berikut ini:

benang-offline-cermin "./"
eksperimental-pack-script-packages-in-mirror true

Setelah penginstalan pertama, modul prebuilt akan aktif
.// prebuilt. yarn.lock juga diperbarui
dengan varian prebuilt

Menarik 66a0143 terbaru
https://github.com/yarnpkg/yarn/commit/66a0143a753cd4ade1a0fffee2174890d564c129 ,
dan sepertinya berfungsi dengan baik😎

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-376989174 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AAUAzz07Js-JQyj9n9_rsYq3cpd9Rp8qks5ti9a2gaJpZM4KVN87
.

@snowyu apakah Anda menghapus yarn.lock, node_modules, dan yarn cache clean ? Apakah ./yarn-offline-mirror/prebuilt terisi setelah penginstalan?

Ini adalah proyek baru dalam temp. Ya, saya dapat melihat file node-sass-4.8.3.tgz di folder cache.
Sekarang, saya menjalankan yarn cache clean . TETAPI MASIH mengunduh biner secara berulang * .

`` pesta

benang init -y
benang tambahkan simpul-sass
benang tambahkan v1.6.0-20180327.1507
info Tidak ditemukan file kunci.
[1/4] Menyelesaikan paket ...
[2/4] Mengambil paket ...
[3/4] Menautkan dependensi ...
[4/4] Membuat paket baru ... Mengunduh biner dari https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
sukses Lockfile disimpan.
sukses Menyimpan 152 ketergantungan baru.
Selesai dalam 11,98 detik.

benang tambahkan simpul-sass
benang tambahkan v1.6.0-20180327.1507
[1/4] Menyelesaikan paket ...
[2/4] Mengambil paket ...
[3/4] Menautkan dependensi ...
[4/4] Membuat paket baru ... Mengunduh biner dari https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
sukses Lockfile disimpan.
sukses Menyelamatkan 1 ketergantungan baru.
info Ketergantungan langsung
└─ [email protected]
info Semua ketergantungan
└─ [email protected]
Selesai dalam 13.45 detik.
``

Oke, saya melakukan repo git sederhana untuk mereproduksi bug ini.

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

benang melakukan pembangunan kembali yang tidak perlu ttf2woff2 ketika saya mencoba menambahkan ketergantungan nol 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 ... ]

Saya dapat mereproduksi ini di kedua sistem OSX host dan di kontainer buruh pelabuhan dengan gambar node

NPM bekerja dengan benar dalam hal ini:

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 ... ]

Versi benang saya 1.5.1

@vlmonk apakah ini masih terjadi jika Anda mengkloning https://github.com/rally25rs/yarn dari @ rally25rs dan menggunakan kode di # 5470 (cabang fix-linking-rebuilding-uws-932 )?

@karlhorky ya, benang masih membangun kembali ttf2woff2 setelah menambahkan left-pad

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

Paket ttf2woff2 dilengkapi dengan file yang diubah pada langkah pembuatan. Pada proses selanjutnya, benang melihat file-file itu berubah dan menginstal ulang paket.

Yarn harus menangani situasi ini dengan lebih baik: Yarn harus melihat bahwa file-file tersebut berubah selama langkah build dan harus menerima file yang diubah tersebut sebagai file yang "benar", tidak memperlakukannya sebagai alasan untuk menginstal ulang.

Saya memeriksa ini dengan logging tambahan (https://github.com/sth/yarn/tree/trace-rebuild). Pada instalasi pertama itu menunjukkan:

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

File paket https://registry.npmjs.org/ttf2woff2/-/ttf2woff2-2.0.3.tgz memang berisi file-file tersebut.

Kami melihat ini dengan OS X juga, menambahkan paket apa pun dengan yarn add memicu kompilasi ulang paket dependen apa pun. Kami memiliki paket node-gyp dengan kode asli, ini membutuhkan waktu lebih dari 1 menit setiap kali paket lain ditambahkan, dan belum ada banyak kode dalam modul asli (ini akan menjadi lebih buruk). Ini dengan benang 1.5.1.

Kami menggunakan yarn add ../a dengan jalur relatif jika itu membuat perbedaan.

Beri tahu saya jika ada solusi, atau kapan akan diperbaiki.

Ini dengan benang 1.5.1.

Masalah ini telah diperbaiki di 1.6.0 yang keluar baru-baru ini.

Saya masih melihat ini dengan 1,6. Sejak pindah dari npm menjadi yarn lama sekali uws seperti biasa dibangun kembali (atau setidaknya yarn telah tertahan di uws selama kira-kira 5-10 detik).

Langkah-langkah untuk mereproduksi:

1. $ benang sudah ketinggalan zaman
2. pilih paket yang sudah ketinggalan zaman
3. $ yarn upgrade [paket]

@grantila dapatkah Anda memberikan package.json atau repo dengan langkah-langkah yang mereproduksi ini dengan Benang 1.6.0 ?

ini masih terjadi di 1.6.0

Anda dapat melakukan repro ini menggunakan https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784 ini

Saya memiliki proyek sederhana dan saya melihat ini juga. Menambah atau menghapus sebuah paket tampaknya memicu pembangunan kembali lengkap setidaknya satu paket setiap saat.

"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"
  }

Setelah ini diinstal, saya menambahkan paket unescape , yang memicu pembangunan kembali sodium . Kemudian saya menghapusnya yang memicu pembangunan kembali apa yang tampak seperti setiap paket yang perlu dikompilasi. Menambahkan paket sederhana ini membutuhkan waktu 36 detik dan menghapusnya membutuhkan waktu 100 detik!

EDIT: menggunakan Node 8.11.1 dan benang 1.6.0 pada Debian Stretch.

@arcanis @ rally25rs mohon buka kembali masalah tersebut, beberapa laporan tentang hal ini masih terjadi, bahkan dengan perbaikan gabungan.

Saya pikir ini lebih merupakan masalah @ rally25rs :)

@grantila an upgrade akan _always_ membangun kembali semua. Ini disengaja. npm melakukan hal yang sama (saya menyebutkan ini dalam komentar di suatu tempat di utas panjang ini.) meskipun kami berpotensi mencoba berhenti melakukan itu. Saya tidak yakin apa akibatnya.

Semua orang lain:

Dalam # 5680 saya menunjukkan bahwa ini masih terjadi jika sebuah paket menghapus file itu sendiri _ (mengapa oh mengapa mereka melakukan hal-hal ini 😿) _ dan benang tidak melacaknya di mana pun (kami melacak file apa yang dibuat atau dimodifikasi), jadi ia hanya mengira paket tersebut kehilangan file dan membangunnya kembali.

Saya kira kita dapat membuka kembali ini, tetapi ini telah diperbaiki untuk sebagian besar paket. Jika ada yang ingin menambahkan "saya juga" ke ini, _please_ berikan package.json Anda, atau sebutkan secara spesifik paket mana yang terus dibangun ulang, karena Anda mungkin memiliki beberapa dependensi yang dapat dibangun ulang dan beberapa tidak.

Siapapun boleh membuat PR untuk ini! (lihat komentar debugging saya di # 5680)

Maaf telah menambahkan lebih banyak kebisingan, tetapi saya ingin menyarankan untuk mengunci masalah ini dan menunjuk ke masalah baru dengan informasi terbaru ini di bagian atas.

Saya pikir masalah di sini telah bergeser sedikit dan setidaknya diselesaikan sebagian. Dengan semua postingan di sini, sulit bagi orang baru untuk mengetahui apa yang telah diperbaiki dan apa yang masih menjadi masalah.

Saya setuju dengan @ james-rabbit

Ya, Anda benar. Saya akan mengunci yang ini agar jawaban @ rally25rs tetap terlihat.

Jika Anda memiliki masalah dengan paket asli:

• Jika ini terjadi dengan setiap ketergantungan asli, buka masalah umum. Masalah ini seharusnya telah diselesaikan, jadi saya tidak berharap untuk melihatnya dalam waktu dekat - namun, jika Anda dapat memberikan langkah-langkah reproduksi, silakan buka masalah baru (dan Anda dapat menautkan ke masalah ini jika Anda mau).

• Jika itu terjadi dengan satu ketergantungan asli