Saya tidak berpikir ini adalah bug. Saya dapat mereproduksi masalah tetapi perbedaannya adalah

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

Perubahan ini hanyalah pengoptimalan lockfile dan tidak mengubah semantik. Kami berencana untuk menambahkan peringatan ketika lockfile membutuhkan pembaruan ketika menjalankan yarn install tetapi jika Anda ingin memastikan file kunci Anda tetap sama dan akurat, Anda harus menggunakan opsi --frozen-lockfile .

Saya harus mengakui bahwa ini agak tidak intuitif dan kami mencoba menemukan solusi yang baik untuk ini. Anda dapat mengikuti atau berkontribusi pada diskusi di # 4147.

Jika Anda setuju bahwa ini bukan bug dan # 4147 adalah tempat yang baik untuk melanjutkan diskusi, silakan tutup masalahnya :)

@BYK terima kasih atas tanggapan bijaksana Anda. Setelah membaca # 4147, saya ragu untuk menutup masalah ini. Saya berharap sedikit lebih banyak diskusi di sini dapat membantu.

4147 tampaknya secara eksklusif tentang kasus di mana yarn.lock dan package.json tidak sinkron - sebenarnya satu-satunya pengoptimalan waktu disebutkan dalam komentar ini: https://github.com/yarnpkg/yarn/issues/4147 #issuecomment -321894341 - dan komentar itu menyentuh masalah yang menyangkut saya: utas memodifikasi file yarn.lock ketika tidak ada perubahan yang dilakukan pada package.json .

Menurut saya, file yarn.lock seharusnya hanya berubah jika dependensi saya berubah. Faktanya, sampai saat ini, saya telah memberi tahu pengembang saya bahwa jika mereka melihat perubahan pada file yarn.lock , inilah waktunya untuk menjalankan yarn install . Dengan peningkatan terbaru beberapa melaporkan kembali bahwa setelah mereka menerima perubahan saya dan mereka menjalankan yarn install , file kunci mereka berubah (pengoptimalan). Ini membuat situasi yang membingungkan - haruskah mereka melakukan perubahan? Haruskah saya melakukan pra-optimasi file kunci (apakah itu mungkin)?

Sepertinya saya mungkin harus, dalam jangka pendek, menambahkan --frozen-lockfile true menjadi .yarnrc di semua repositori saya - tetapi saya bukan penggemar berat solusi ini karena menghalangi alur kerja yang disebutkan di # 4147 di mana Anda mengedit package.json dan kemudian menjalankan yarn install .

Apakah niat bahwa setiap pemanggilan benang dapat mengubah yarn.lock ?

@BYK Saya minta maaf mengganggu Anda tentang ini karena saya tahu Anda sangat sibuk - tetapi saya berharap mendapatkan jawaban yang pasti tentang ini. Alur kerja saya untuk mendistribusikan perubahan ketergantungan ke tim saya telah beralih ke ini:

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

Tampaknya ini memperbarui file kunci dengan benar (lihat # 4476), dan kemudian mengoptimalkan file kunci sehingga rekan satu tim saya tidak memeriksa perubahan file kunci.

Apakah tim saya menggunakan benang secara tidak benar? Haruskah kita mengharapkan file kunci berubah dengan setiap install perintah?

@artlogic IMHO, rekan satu tim Anda harus diizinkan untuk memeriksa perubahan lockfile meskipun itu hanya pengoptimalan. Saya setuju dengan anggapan bahwa yarn install mengoptimalkan lockfile adalah kontra-intuitif, namun masih merupakan sesuatu yang dapat dilakukan dengan aman oleh setiap pengembang tim Anda. Saya tidak mengerti mengapa Anda ingin melarang itu.

Yang sedang berkata, alur kerja Anda mungkin menyebabkan efek samping yang tidak terduga, karena Anda cukup banyak melepaskan versi terkunci. Menghapus lockfile berarti bahwa benang harus menyelesaikan semua versi dependensi lagi, dan itu akan mencoba untuk mengambil versi terbaru seperti yang ditunjukkan dalam package.json mengarah ke potensi kerusakan, esp. jika lebih dari satu ketergantungan putus pada saat yang sama di versi mendatang.

Jika Anda masih ingin memastikan bahwa penginstalan tidak menyentuh file kunci, Anda harus menggunakan tanda frozen-lockfile :

 yarn add {blah}

Periksa di lockfile, dan dev lain akan menggunakan:

   yarn install --frozen-lockfile

JANGAN TAMBAHKAN --frozen-lockfile menjadi true di .yarnrc karena hal itu mencegah Anda untuk memperbarui, lihat: # 4570

Jika Anda ingin mengupgrade dependensi Anda, jalankan:

 yarn upgrade

Jika Anda hanya ingin meningkatkan satu dependensi:

  yarn upgrade {blah}

Anda juga dapat menginstal versi tertentu dari satu dependensi:

  yarn install {blah}@1.5

Ini memungkinkan penyetelan yang lebih baik dan lebih sedikit sakit kepala dalam jangka panjang.

@ k0pernikus - terima kasih atas tanggapan rinci Anda. Pertama, saya harus meminta maaf karena menggabungkan dua masalah - # 4476 mendorong sebagian alur kerja saya. Fakta bahwa yarn upgrade tampaknya agak rusak tidak ada hubungannya dengan masalah ini, tentu saja.

Adapun alur kerja, saya tidak bisa membayangkan saya adalah satu-satunya tim di mana satu pengembang bertanggung jawab untuk memelihara / menguji ketergantungan baru sementara pengembang lain bekerja pada basis kode. Masalah besar yang saya miliki dengan apa yang telah mulai terjadi adalah bahwa saya akan menginstal / menguji dependensi baru, memberi tahu semua orang untuk menjalankan yarn install dan kemudian mendapatkan 4-5 pertanyaan tentang apakah perubahan yarn.lock harus dilakukan . Sepertinya saya akan berada di tempat yang lebih buruk jika saya mengatakan "jika lockfile berubah, lakukan" karena pada titik itu saya bisa berakhir dengan kunci commit yang terlihat seperti ini:

• yarn.lock berubah (dev4)
• yarn.lock berubah (dev3)
• yarn.lock berubah (dev2)
• yarn.lock berubah (dev1)
• Dependensi yang diperbarui (saya)

Namun, bisa jadi ini hanyalah cara benang dimaksudkan untuk bekerja, jadi untuk proyek tim saya, kami akan mengubah semua repo kami untuk menggunakan file kunci beku sehingga hanya add dan upgrade menyebabkan lockfile untuk mengubah.

Satu skenario tambahan ... sepertinya ini bisa menjadi gangguan potensial untuk proyek dengan banyak kontributor karena berpotensi setiap kali mereka mengkloning dan menginstal, lockfile mungkin berubah. Saya pasti tidak ingin pengoptimalan ini dalam permintaan tarik. Apakah niat bahwa sebagian besar proyek FOSS menggunakan transisi benang ke file lockfile juga?

@artlogic Tim kami memiliki --install.pure-lockfile true dalam proyek .yarnrc untuk alasan ini.

@ Jboler - Saya belum pernah melihat pengaturan itu sebelumnya. Saya harus melihatnya, tetapi sepertinya saya akan menyarankan agar kami menambahkannya ke .yarnrc untuk semua repo kami, dan semua repo dari setiap proyek FOSS yang saya miliki.

Jika seseorang dari tim benang dapat mengkonfirmasi bahwa tujuannya adalah bahwa yarn install dapat dan akan mengubah file kunci pada setiap proses (meskipun tidak ada perubahan pada ketergantungan) maka saya akan menutup masalah ini.

@artlogic maaf atas tanggapan yang terlambat.

Masalahnya adalah, __ terduga__ yarn install berpotensi mengubah file kunci. Saya tahu ini tidak ideal dan membutuhkan komunikasi yang lebih baik. Saya benar-benar ingin memiliki default yang lebih baik tetapi sementara itu, saya pikir sesuatu seperti @jboler menyarankan tetapi mungkin menggunakan --frozen-lockfile sebagai gantinya, akan menjadi solusi terbaik sampai kita mengetahui bagaimana benang harus berperilaku di bawah skenario yang berbeda seperti untuk alur kerja di mana orang lebih suka mengedit package.json untuk memperbarui dependensi daripada menggunakan yarn add dll.

@BYK Saya setuju dengan @artlogic . Perilaku ini sangat membingungkan:

Masalah besar yang saya miliki dengan apa yang telah dimulai terjadi adalah bahwa saya akan menginstal / menguji dependensi baru, memberi tahu semua orang untuk menjalankan pemasangan benang dan kemudian mendapatkan 4-5 pertanyaan tentang apakah yarn.lock yang diubah harus dilakukan.

Tim kami terdiri dari ~ 50 orang yang menjalankan yarn install setiap hari :(

@vkrol Anda seharusnya dapat memeriksa file .yarnrc yang memiliki --install.frozen-lockfile true atau --install.pure-lockfile true untuk menghindari masalah sampai Yarn mengubah perilakunya. Apakah itu membantu?

@BYK pure-lockfile akan membantu kita, tetapi bukan frozen-lockfile . Jika saya mengerti dengan benar yarn install akan gagal dengan kesalahan jika beku-lockfile diaktifkan. Perilaku ini sama sekali tidak dapat diterima dalam kasus kami.

@vkrol preferensi saya adalah frozen-lockfile karena akan gagal hanya jika file kunci Anda perlu diubah dan tidak konsisten. Dengan pure-lockfile Anda mungkin memiliki file kunci yang hampir tidak berguna atau sangat tidak akurat tetapi Anda tetap tidak akan mendapatkan kegagalan. Benang hanya akan menggunakan resolusi internal yang dihitungnya dengan senang hati. Jika semua anggota tim Anda menggunakan versi Yarn yang sama persis, ini tidak masalah. Jika tidak, bisa berbahaya.

@BYK mungkin saya kurang memahami perilaku frozen-lockfile dengan benar. Apakah gagal ketika lockfile konsisten dengan konten package.json, tetapi diperlukan beberapa pengoptimalan internal?

@vkrol seharusnya tidak gagal ketika file dapat dioptimalkan lebih jauh tetapi konsisten dengan package.json dan konsisten dalam dirinya sendiri. Jika tidak, ini adalah bug. Bahkan ada tes untuk ini: https://github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__/commands/install/lockfiles.js#L72 -L84

@BYK Saya tidak tahu tentang itu. Saya akan mencoba opsi ini, terima kasih! Saya pikir fakta ini harus didokumentasikan di suatu tempat.

@Yuk

seharusnya tidak gagal ketika file dapat dioptimalkan lebih jauh tetapi konsisten dengan package.json dan konsisten dalam dirinya sendiri.

Saya menemukan beberapa kelemahan dari penggunaan bendera ini. Jika yarn.lock dapat dioptimalkan daripada pemanggilan berulang dari perintah ini yarn install --frozen-lockfile tidak dioptimalkan melalui pemeriksaan "integritas" karena tanpa tanda ini. Apakah ini bug? Apakah saya perlu membuat masalah terpisah?

@BYK Terima kasih atas tanggapan Anda. Untuk proyek tim saya, kami sekarang menggunakan frozen-lockfile dan semuanya berjalan (relatif) baik-baik saja. Masalah ini tetap agak mengkhawatirkan bagi saya. Secara khusus, benang pengoptimalan yang tidak perlu dilakukan ke file kunci saat menjalankan yarn install .

Inilah contoh paling jelas yang dapat saya berikan tentang di mana perilaku ini menyebabkan masalah:

1. Saya menambahkan ketergantungan baru menggunakan yarn add [blah] dan mengkomit package.json dan yarn.lock .
2. Kontributor paket saya menarik perubahan dan melihat bahwa yarn.lock telah diperbarui, dan dengan demikian menjalankan yarn install .
3. Dalam beberapa kasus, kontributor ini mendapatkan yarn.lock dimodifikasi setelah penginstalan. Apa yang harus mereka lakukan dalam kasus ini? Apakah ini perlombaan untuk melihat siapa yang bisa mengajukan pull request terlebih dahulu?

Untuk lebih jelasnya, saya tidak punya masalah dengan yarn install memodifikasi yarn.lock jika package.json telah dimodifikasi. Masalah saya adalah pengoptimalan saat package.json belum diubah. Saya melihat tiga solusi yang mungkin:

1. Arahkan proyek apa pun yang mengelola dependensi secara terpusat untuk menambahkan --install.frozen-lockfile true ke file .yarnrc . Ini kemungkinan besar akan BANYAK proyek - sebagian besar paket NPM menurut saya.
2. Sediakan sakelar untuk memaksa benang untuk mengoptimalkan file kunci selama fase penambahan, misalnya yarn add --optimize [blah] . Kemudian, arahkan pengelola paket untuk selalu menggunakan sakelar itu.
3. Larang thread untuk mengoptimalkan yarn.lock selama tahap penginstalan kecuali package.json tampaknya telah diperbarui.

Saya menganjurkan opsi 3, tetapi saya dapat melihat opsi 2 sebagai pilihan yang masuk akal juga.

Terima kasih atas waktunya!

Saya menyukai gagasan bahwa yarn install tidak memperbarui file yarn.lock tetapi mengeluarkan peringatan yang mengatakan bahwa "File yarn.lock Anda kedaluwarsa, jalankan yarn blah untuk perbarui sekarang`.

@BYK mengapa ~ tidak ~ apakah benang menerapkan pengoptimalan ke yarn.lock pada yarn install daripada saat add / upgrade dijalankan?

edit: perbaiki kesalahan ketik

@ spencer-brown: berdasarkan apa yang saya lihat, ini sebenarnya menerapkan pengoptimalan saat penginstalan - itulah yang menurut saya bermasalah

Bukankah optimalisasi ke yarn.lock harus dijalankan pada yarn add? yarn.lock akan tetap berubah. Ini adalah opsi nomor dua dalam komentar terbaru @artlogic , bukan? Mengapa pengoptimalan tidak terjadi, jadi tidak ada orang lain yang harus melakukan perubahan yarn.lock lain?

@artlogic oops, typo :) - komentar saya harus mengatakan "tidak"; diedit.

Kami banyak menggunakan komposer dan composer install tidak pernah menyentuh file kunci.

composer update atau composer require (setara dengan yarn add ) harus dijalankan untuk setiap perubahan atau optimasi yang akan dilakukan pada file kunci.

Selama bertahun-tahun, kami tidak pernah khawatir tentang perilaku ambigu composer install .

Saya menyadari benang mengisi peran yang sedikit berbeda, tetapi komposer memiliki masalah yang setara dengan pembaruan manual yang dibuat menjadi composer.json dan itu tidak sinkron dengan file kunci. Saat ini, composer install akan sepenuhnya mengabaikan file composer.json dan mengeluarkan peringatan.

Kami banyak menggunakan komposer dan composer install tidak pernah menyentuh file kunci.

composer update atau composer require (setara dengan yarn add ) harus dijalankan untuk setiap perubahan atau optimasi yang akan dilakukan pada file kunci.

Selama bertahun-tahun, kami tidak pernah khawatir tentang perilaku ambigu composer install .

Saya menyadari benang mengisi peran yang sedikit berbeda, tetapi komposer memiliki masalah yang setara dengan pembaruan manual yang dibuat menjadi composer.json dan itu tidak sinkron dengan file kunci. Saat ini, composer install akan sepenuhnya mengabaikan file composer.json dan mengeluarkan peringatan.

hai anak-anak, file kunci tidak boleh berubah pada penginstalan berikutnya. itu hanya bodoh. jika Anda merasa bahwa pengoptimalan layak untuk disentuh, cukup buat file terpisah sebagai gantinya yang tidak masuk ke kontrol versi.

Seperti halnya Gemfile.lock Bundler, inti dari yarn.lock adalah bahwa setiap kali pemasangan benang dijalankan, Anda dapat menjamin hasil deterministik di semua lingkungan. Jika pemasangan benang mengubah file kunci, Anda kehilangan jaminan itu. Perintah lain seperti penambahan benang atau pembaruan benang jelas harus mengubah kunci benang tetapi pemasangan benang tidak boleh. Tim kami mengalami masalah di mana kami memiliki versi paket yang sedikit berbeda yang diinstal di lingkungan berbeda yang sebenarnya tidak kami inginkan.

Saya cenderung berpikir bahwa yarn install --pure-lockfile harus menjadi default, dan mungkin ada opsi --fix-my-dev-process-inconsistencies-for-me-magically untuk mendapatkan perilaku saat ini.

@ryancastle --pure-lockfile tidak akan memberi tahu Anda bahwa pembaruan adalah untuk file kunci Anda. Itu tidak hanya menghasilkan satu. Ini mungkin masih mengarah pada perilaku yang tidak terduga. --frozen-lockfile akan gagal jika pembaruan diperlukan.

Saya telah mengoperasikan dengan --install.frozen-lockfile true di .yarnrc untuk sementara waktu sekarang dan tampaknya bekerja dengan cara yang waras. Triknya adalah membuat yarn.lock untuk repo tanpa tanda itu berlaku. Setelah dibuat, penginstalan tidak dapat mengubah yarn.lock , tetapi pembaruan dapat. Setelah saya mulai menggunakan alur kerja ini, jumlah perubahan yang tidak disengaja menjadi yarn.lock turun ke nol.

@artlogic Sidenote: Saya dulu memiliki frozen-lockfile true di .yarnrc juga, sekarang saya hanya memberlakukannya di build server, karena kami mengalami masalah adalah perubahan yang disengaja ke yarn.lock tidak dibuat, misalnya saat mencoba menyinkronkan package.json diubah menjadi yarn.lock , karena pengembang secara manual mengedit package.json atau menggunakan npm untuk menambahkan dependensi.

Lihat: https://github.com/yarnpkg/yarn/issues/4570

Kasus penggunaan --frozen-lockfile sebagai default dengan yarn install . Sejujurnya saya tidak tahu apa kompromi yang baik tanpa menghalangi orang yang mengedit package.json dan kemudian menjalankan yarn install untuk memperbarui lockfile. Saya mengusulkan sebuah bendera atau perintah baru seperti yarn sync tetapi idenya harus disempurnakan dan kemudian dinilai oleh komunitas sebelum diterapkan.

Selain itu, ini akan menjadi perubahan besar sehingga membutuhkan Yarn 2.x :)

bendera atau perintah baru seperti sinkronisasi benang

kedengarannya bagus untukku 👍. dan yarn install bisa menunjukkan pemberitahuan "package.json dan yarn.lock tidak sinkron. Jalankan 'yarn sync' untuk memperbarui lockfile"

Sejujurnya saya tidak tahu seperti apa kompromi yang baik tanpa menghalangi orang-orang yang mengedit package.json dan kemudian menjalankan yarn install untuk memperbarui lockfile.

Saya pikir pada titik tertentu keputusan perlu dibuat sebagai alur kerja yang sesuai. Bagi saya, mengaktifkan ini hampir seperti mendorong anti-pola.

Saya mengusulkan bendera atau perintah baru seperti sinkronisasi benang tetapi idenya perlu disempurnakan dan kemudian dinilai oleh komunitas sebelum diterapkan.

Bagi saya, ini sepertinya kompromi yang masuk akal. Jika Anda bersikeras untuk mengedit package.json , maka menjalankan perintah untuk menyinkronkan semuanya menjadi masuk akal.

Inilah yang ingin saya lihat:

• yarn install tanpa yarn.lock membuat yarn.lock .
• yarn install dengan yarn.lock tidak mengubahnya. Jika ditemukan ada perbedaan antara yarn.lock dan package.json kesalahan dikembalikan (seperti @indeyets ditunjukkan).
• yarn sync (atau mungkin yarn install -s ) mendapatkan yarn.lock kembali disinkronkan dengan package.json .

Saya masih memiliki kekhawatiran mendasar bahwa yarn install memodifikasi yarn.lock bahkan ketika package.json tidak tidak sinkron dengan file kunci. Anda akan melihat di atas itu melakukan beberapa "pengoptimalan". Apakah mungkin untuk setidaknya menonaktifkan perilaku ini tanpa perubahan yang merusak?

Saya masih memiliki kekhawatiran yang mendasar bahwa pemasangan benang memodifikasi yarn.lock bahkan ketika package.json tidak sinkron dengan file kunci. Anda akan melihat di atas itu melakukan beberapa "pengoptimalan". Apakah mungkin untuk setidaknya menonaktifkan perilaku ini tanpa perubahan yang merusak?

Sentimen yang sama di sini. Saya pikir inilah alasan khusus untuk masalah ini tetap terbuka. Saat "sinkronisasi" dibahas di # 4147

Itu sebabnya saya mencari masalah ini di tempat pertama.

Haruskah kita menggabungkan ini dan # 4147?

@BYK Saya rasa hampir semua hal yang telah dibahas di sini dapat digabungkan dengan # 4147. Seperti yang telah saya katakan sebelumnya, saya pikir satu-satunya hal yang masih menjadi perhatian saya adalah "pengoptimalan" yang dilakukan yarn install pada yarn.lock bahkan ketika tidak ada perubahan pada package.json .

Pemikiran saya adalah sebagai stop-gap menuju benang 2.0, pengoptimalan ini harus dinonaktifkan. Saya tidak berpikir ini akan menjadi perubahan yang menghancurkan.

Saya 100% setuju dengan @artlogic .

Saya sedang menyiapkan CircleCI dan bangunan saya terus gagal dan saya melacaknya sampai ke masalah cache dengan yarn.lock . Berasal dari Rails, saya berharap file kunci dikunci dengan perintah instal.

Inilah yang disarankan untuk pemeriksaan cache di CircleCI: https://circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

Ini tidak akan pernah berhasil karena yarn.lock dapat berubah, padahal seharusnya tidak.

FYI, pada benang 1.10.1 di bawah macOS 10.13.6, saya baru saja mencoba stimulus bug OP, dan menemukan bahwa yarn.lock tidak berubah. Dengan kata lain, ketika saya mencoba:

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

Jadi, saat menggunakan benang 1.10.1, yarn install tidak berubah yarn.lock , seperti yang terjadi pada OP saat menggunakan benang 1.0.1. (Saya menganggap ini hal yang baik, seperti yang saya pikirkan tentang OP.)

@dtgriscom Bagus sekali masalah ini tidak terjadi lagi untuk Cordova! Saya bertanya-tanya apakah itu telah diperbaiki seluruhnya atau apakah benang masih mungkin mencoba mengoptimalkan file kunci saat menginstal?

Alangkah baiknya mengetahui, bukan? Anda mencatat bahwa masalahnya adalah khusus paket; masuk akal bahwa mungkin versi khusus juga. (Saya tidak pernah mendengar alasan untuk "kami ingin mengubah sesuatu yang seharusnya tidak berubah"; selain "kami sedang mengoptimalkan" ...)

Saya sepenuhnya setuju bahwa operasi install harus deterministik secara default. Memperbarui file .lock harus meminta pengembang untuk melakukan tindakan yang dia tahu akan menghasilkan perubahan dalam file. Misalnya, Anda dapat menjalankan sesuatu seperti yarn install --optimize yang akan memungkinkan pengoptimalan kecil yang tidak merusak status paket saat ini.

Menambahkan opsi terpisah yang harus saya lihat ke dokumentasi agar saya dapat yakin bahwa file kunci saya tidak tersentuh tanpa izin saya cukup membingungkan, terutama jika dapat menyebabkan kegagalan. Sebagai pengembang, saya berharap memiliki kendali atas alat yang saya gunakan dan saya merasa perilaku ini merampasnya dari saya.

Harap pertimbangkan kembali membalik perilaku default untuk tidak mengubah file kunci dan hanya mengoperasikannya saat menginstal dependensi. Pemeriksaan integritas dengan peringatan bahwa package.json tidak sinkron dengan file kunci yang benar-benar dibutuhkan semua orang.

Saya telah memberi tahu orang-orang bahwa PR termasuk perubahan pada file kunci tidak akan digabungkan karena file kunci hanya diubah saat menambahkan dependensi baru atau memperbarui. Inilah yang dinyatakan oleh dokumentasi instal :

yarn install

Instal semua dependensi yang terdaftar dalam package.json di folder lokal node_modules .

File yarn.lock digunakan sebagai berikut:

• Jika yarn.lock ada dan cukup untuk memenuhi semua dependensi yang terdaftar di package.json , versi persis yang tercatat di yarn.lock diinstal, dan yarn.lock tidak akan berubah . Benang tidak akan memeriksa versi yang lebih baru.
• Jika yarn.lock tidak ada, atau tidak cukup untuk memenuhi semua dependensi yang terdaftar di package.json (misalnya, jika Anda secara manual menambahkan dependensi ke package.json ), Yarn mencari versi terbaru tersedia yang memenuhi batasan dalam package.json . Hasilnya ditulis menjadi yarn.lock .

Jika Anda ingin memastikan yarn.lock tidak diperbarui, gunakan --frozen-lockfile .

Apakah dokumentasinya salah karena ada pengoptimalan yang dapat terjadi seperti yang disebutkan di atas atau apakah ini bug yang harus diperhitungkan untuk saat ini?

ps. itu masih terjadi, dan yarn --frozen-lockfile tidak gagal ketika gagal.

Saat ini saya menggunakan --frozen-lockfile dalam file .yarnrc , yang secara efektif mencegah thread memodifikasi file yarn.lock saat menjalankan yarn install pada mesin yang berbeda. Tetapi ini juga mencegah yarn add blahblah dari memodifikasi yarn.lock saya. Apakah itu perilaku yang benar atau saya melewatkan sesuatu? Saya telah membaca seluruh utas dan menurut saya --frozen-lockfile adalah pendekatan yang disarankan untuk saat ini?

@konekoya Ya, kamu benar yang HARUS kamu gunakan saat ini

yarn install --frozen-lockfile

dan tidak dapat mengandalkan pengaturan di .yarnrc karena akan mencegah yarn.lock diperbarui.

Bergantung pada konten Anda .npmrc dan .yarnrc Anda mungkin dapat menggunakan

yarn install --no-default-rc {dependency}

tapi saya tidak akan mengandalkan itu (karena akan rusak segera setelah Anda memiliki pengaturan lain di rc-files Anda.)

Lihat komentar saya dan masalah yang relevan: # 4570, esp. kesimpulan saya.

Terima kasih telah menyelesaikannya di @ k0pernikus. Kau mencerahkan hariku :)

@BYK mengapa benang menerapkan pengoptimalan ke yarn.lock pada yarn install daripada saat add / upgrade dijalankan?

Saya pikir komentar @ spencer-brown di sini adalah kunci untuk "memperbaiki" masalah ini. Saya baru saja menguji diri saya sendiri dan menjalankan yarn upgrade dan kemudian yarn Saya diberitahu "Sudah up-to-date.". Jadi saya menghapus node_modules dan menjalankan yarn yang kemudian menghasilkan lockfile yang "dioptimalkan" yang akan berakhir oleh developer lain dalam proyek saya jika saya mendorong yang saya dapatkan dari yarn upgrade .

Sekarang jika yarn upgrade (dan yarn add ) akan menjalankan pengoptimalan yang sama seperti yarn install kami tidak akan mengalami masalah ini sejak awal. Ada banyak pembicaraan tentang tidak ingin merusak fungsionalitas yang ada dan saya tidak melihat menjalankan pengoptimalan setelah yarn upgrade dan yarn add sebagai melanggar apa pun - hanya membuatnya sedikit lebih lambat.

Sebagai solusinya, saya berpikir untuk menginstruksikan semua pengembang kami untuk menghapus node_modules setiap kali mereka perlu memperbarui file kunci untuk memaksa "pengoptimalan" sebelum mendorong file kunci ke orang lain. Atau mungkin mereka dapat menjalankan yarn upgrade && yarn prune - mungkin itu akan berhasil?

Sebagai solusinya, saya berpikir untuk menginstruksikan semua pengembang kami untuk menghapus node_modules setiap kali mereka perlu memperbarui file kunci untuk memaksa "pengoptimalan" sebelum mendorong file kunci ke orang lain. Atau mungkin mereka dapat menjalankan yarn upgrade && yarn prune - mungkin itu akan berhasil

Pembaruan: Anda tidak dapat menjalankan pemangkasan secara manual, Anda hanya mendapatkan pesan ini: _ "Perintah pemangkasan tidak diperlukan. yarn install akan memangkas paket asing" ._ Dan karena Anda juga tidak dapat menjalankan pemasangan karena Anda adalah _ "Sudah up-to-date" _ Saya rasa kita akan menghapus node_modules dan kemudian menjalankan yarn untuk melakukan pemangkasan.

Bagi saya, satu-satunya nilai jual terbesar untuk yarn adalah perilaku file kunci yang dapat diprediksi dan dapat diandalkan. Mengubah file kunci pada yarn install membuat saya cemas.

Bagi saya, satu-satunya nilai jual terbesar untuk yarn adalah perilaku file kunci yang dapat diprediksi dan dapat diandalkan. Mengubah file kunci pada yarn install membuat saya cemas.

File kunci disajikan sebagai spesifikasi yang tepat tentang apa yang akan diinstal, sehingga kita tidak perlu khawatir tentang apa yang akan diinstal. Gunakan file kunci yang sama, dan Anda akan mendapatkan penginstalan yang sama setiap saat. Tetapi kadang-kadang yarn akan, atas inisiatifnya sendiri, karena alasannya sendiri, dan tanpa peringatan, mengubah konten file kunci. Ya, Anda dapat berargumen bahwa "perubahan file tidak mengubah apa yang akan diinstal", tetapi mengapa mengambil jaminan yang begitu jelas dan mengacaukannya? Mengapa membuat saya bertanya-tanya apakah saya harus melakukan kembali file kunci yang diubah? Mengapa menodai klaim utama Anda untuk ketenaran?

Ini benar-benar luar biasa. Yang lain sudah menyatakannya dengan baik. File kunci tidak boleh berubah saat menginstal. Ini berdampak negatif pada alur kerja komit. Setiap pengembang di tim kami tahu dalam keadaan apa lockfile diizinkan untuk diubah. Ketika lockfile berubah tanpa dependensi diperbarui, itu menyebabkan kebingungan yang tidak perlu dan pemeriksaan ekstra. Ini adalah pengelola paket dasar UX yang baru saja rusak. Tolong perbaiki.

Saya baru saja terkejut dengan perilaku ini, ketika berpindah dari Node.js 13 ke 14 semua file yarn.lock berubah ketika melakukan yarn install dan saya bertanya-tanya mengapa ...

Saya pikir perilaku yang tepat adalah mengeluarkan peringatan jika _optimizing_ file yarn.lock dengan cara apapun.