Yarn: jadikan `--pure-lockfile` sebagai default untuk `install`

Dibuat pada 10 Okt 2016  ·  54Komentar  ·  Sumber: yarnpkg/yarn

Apakah Anda ingin meminta _fitur_ atau melaporkan _bug_?

_fitur_

Apa perilaku saat ini?

Tidak melewati --pure-lockfile untuk install perintah membingungkan saya karena memodifikasi file kunci saat menginstal node_modules.
Kami menyetujui semantik bahwa add/upgrade/remove adalah untuk mengubah dependensi dan install adalah untuk secara konsisten membangun kembali node_modules dari lockfile.

Konsistensi hilang ketika lockfile dimodifikasi tergantung pada lingkungan (versi benang yang saat ini diinstal).

Apa perilaku yang diharapkan?

Tidak menulis yarn.lock atau package.json saat melakukan yarn install .
Untuk memperbarui yarn.lock gunakan yarn upgrade

Sebutkan versi node.js, benang, dan sistem operasi Anda.

benang 0.14

cat-feature needs-discussion

Komentar yang paling membantu

Ada banyak hal berbeda yang terjadi di sini yang ingin saya coba ungkap (tidak ada permainan kata-kata).

Pertama, orang-orang telah mengajukan sejumlah persyaratan berbeda yang menurut saya tidak kontroversial (dan yang membuat beberapa perilaku yang ada menjadi bug, yang akan segera saya selesaikan).

Dari laporan bug asli.

Konsistensi hilang ketika lockfile dimodifikasi tergantung pada lingkungan (versi benang yang saat ini diinstal).
Apa perilaku yang diharapkan?
Tidak menulis yarn.lock atau package.json saat melakukan instalasi yarn.
Untuk memperbarui yarn.lock gunakan peningkatan benang

Untuk lebih tepatnya, semantik yang diharapkan, menurut saya, adalah:

  • jika package.json tidak berubah sejak terakhir kali yarn.lock diubah, yarn.lock adalah sumber kebenaran dan tidak boleh diperbarui.
  • jika package.json telah berubah sejak terakhir kali, yarn.lock berubah, perbarui yarn.lock sehingga memenuhi package.json dan perbarui node_modules .
  • jika yarn update dijalankan, selesaikan kembali semua dependensi dan dapatkan versi terbaru dari semua yang memenuhi package.json .

Ini berarti bahwa ketika repositori pertama kali dikloning pada mesin , jika yarn.lock diperiksa, benang harus selalu memperlakukannya sebagai sumber kebenaran, tidak menghasilkan pembaruan ke yarn.lock , dan melompat langsung ke langkah pengambilan.

Sejauh ini bukan perilaku benang saat ini, saya percaya itu akan menjadi bug.


@esphen menulis:

Saya setuju. Harus ada diskusi tentang mengapa yarn install menulis lockfile secara default di tempat pertama, karena tampaknya bertentangan dengan seluruh konsep lockfile. Mengapa memiliki lockfile jika tidak mengunci versi secara default?

Saya pikir apa yang coba dikatakan ini adalah bahwa benang tidak boleh menulis file kunci baru jika yang sudah ada masih mutakhir. Saya setuju dengan itu.

Saya setuju dengan pendapat @bestander bahwa hanya tindakan bermutasi yang harus memperbarui file kunci secara default, yaitu tambah/tingkatkan/hapus.

Masalah utama di sini adalah apakah perubahan pada package.json akan menyebabkan yarn.lock diperbarui. Menurut pendapat saya, jika perubahan ke package.json tidak dipenuhi oleh yarn.lock , itu harus memperbarui yarn.lock .

Sebuah invarian penting dari sistem lockfile seperti benang adalah bahwa, dengan menggunakan alur kerja normal, pengembang dapat yakin bahwa paket yang benar-benar digunakan ketika mereka menjalankan aplikasi mereka cocok dengan versi yang ditentukan dalam package.json . Jika package.json dibiarkan tidak sinkron dengan yarn.lock , ini tidak akan benar, dan satu-satunya cara untuk mengetahuinya adalah agar pembaca manusia membaca yarn.lock dengan cermat

Cara terbaik bagi sebagian besar pengguna untuk berpikir tentang lockfile adalah bahwa itu adalah artefak dari benang yang sedang berjalan yang mewakili versi yang tepat dari semua paket yang digunakan untuk package.json . Dengan memeriksanya, kolaborator lain, CI, dan kode produksi dijamin untuk menggunakan versi yang sama.


@Guuz berkata:

Jadi, untuk memeriksa apakah saya memahami ini dengan benar:
benang menginstal semua dependensi dan juga memodifikasi file kunci. Pada server CI Anda harus menggunakan yarn install --pure-lockfile?

Pertanyaan ini menggemakan sentimen yang dibuat beberapa orang di utas ini.

Kargo memiliki bendera --locked yang mengatakan "jika package.json tidak puas dengan yarn.lock , itu adalah kesalahan yang sulit". Bundler memiliki flag serupa ( --frozen ), yang ditambahkan ketika Heroku mengadopsi Bundler, untuk memberikan kesalahan besar kepada orang-orang jika mereka membuat perubahan lokal pada Gemfile dan lupa memeriksa Gemfile.lock .

Idenya adalah bahwa selama pengembangan normal Anda, Anda ingin dapat membuat perubahan pada package.json dan memiliki yarn memastikan bahwa yarn.lock tetap sinkron (sekali lagi, untuk memastikan bahwa versi yang ditentukan di package.json selalu cocok dengan apa yang digunakan dalam praktik).

Tetapi ketika menerapkan, hampir selalu merupakan kesalahan untuk menyimpang, karena itu berarti Anda membuat perubahan ke package.json , menjalankan perintah yarn , dan lupa memeriksa yarn.lock . Ini berarti bahwa versi di package.json Anda tidak cocok dengan versi sebenarnya yang digunakan saat aplikasi dijalankan , yang menurut kami melanggar invarian dasar benang.


@esfen berkata:

Menurut pendapat saya, salah satu peran yang diisi oleh manajer paket adalah membuatnya semudah mungkin untuk memulai pengembangan sebuah proyek. Pemasangan benang sederhana harus mendapatkan semua paket yang Anda butuhkan untuk mulai mengembangkan, tanpa kebingungan yang terlibat.

Saya pikir ini tidak kontroversial.

Dengan npm saya memiliki banyak contoh pengembang bergabung dengan sebuah proyek, hanya untuk menemukan sebuah proyek tidak berfungsi di mesin mereka. Instance ini terjadi karena dependensi sementara yang menabrak versi ke versi dengan perubahan yang melanggar atau tidak mengikuti semver. Saya berharap benang akan menyelesaikan masalah ini, tetapi jika kesimpulannya adalah bahwa semua pengembang pada suatu proyek harus menjalankan yarn install --pure-lockfile agar 100% yakin bahwa proyek tersebut akan dibangun, maka bukan itu masalahnya.

Menjalankan yarn install --pure-lockfile akan berarti bahwa lockfile akan dihormati bahkan jika versi di dalam lockfile bertentangan dengan versi yang ditentukan dalam package.json . Ini seharusnya hanya muncul di tempat pertama jika pengembang lupa untuk memeriksa yarn.lock setelah membuat perubahan pada package.json .

Peran lain dari manajer paket adalah memberikan kendali proyek atas dependensinya. Jika dibuat murni secara default, pengembang dapat melihat benang usang untuk melihat versi usang dan kemudian meninjau catatan perubahan, menghindari perubahan yang melanggar. Ini akan memberi pengembang kontrol penuh untuk hanya menabrak versi dalam jangka waktu rilis yang diberikan alih-alih melarang pengembang melakukan git commit -a untuk menghindari komit lockfile yang tidak disengaja.

Jika package.json tidak berubah, menurut saya itu adalah bug jika yarn.lock diperbarui. Setidaknya satu kasus bug tampaknya ada di laporan asli:

lockfile dimodifikasi tergantung pada lingkungan (versi benang yang saat ini diinstal).

Saya pikir ini adalah kesalahan dan harus diperbaiki.

Kemudian di utas, @thejameskyle berkata:

Bayangkan sebuah fungsi memoize di mana inputnya adalah package.json dan outputnya adalah yarn.lock.

Itu persis model mental yang tepat, menurut saya (" yarn.lock dapat berubah jika dan hanya jika package.json berubah"), dan jika abstraksi bocor, kita harus memperbaikinya.


@adamchainz berkata:

Info lebih lanjut tentang hal di atas: build kami memiliki skrip kopi dari Github sebagai subdependensi. coffeescript mendorong beberapa komit dan kami mendapatkan yarn.lock yang dimodifikasi dalam proses pembuatan kami dari menjalankan hanya pemasangan benang

dan kemudian:

Tetapi memang memiliki perilaku buruk jika ketergantungan sedang diinstal dari github, seperti yang saya laporkan di atas

Masalahnya di sini adalah bahwa benang tidak memperlakukan git sha sebagai bagian dari versi terkunci dari dependensi git. Cargo dan Bundler keduanya memiliki konsep versi "tepat" yang diserialkan ke file kunci; untuk sumber git, versi "tepat" adalah SHA. Kemudian, ketika Anda membuat klon baru hanya dengan package.json dan yarn.lock dan menjalankan yarn , semua informasi yang diperlukan untuk mendapatkan kode yang Anda butuhkan ada di sana.

Saya harus mengakui bahwa saya melewatkan interaksi ini ketika meninjau kode git asli; ada beberapa pelacakan SHA dalam kode, tetapi yarn install tidak memastikan bahwa grafik ketergantungan terhidrasi menghormatinya.


TL;DR

Saya setuju dengan @thejameskyle dan @kittens bahwa yarn.lock harus disinkronkan dengan package.json secara otomatis, karena saya percaya bahwa pengguna harus dapat mengasumsikan bahwa versi yang ditentukan dalam package.json sejalan dengan apa yang digunakan saat aplikasi mereka dijalankan.

Namun, tampaknya ada beberapa bug yang menyebabkan churn yang tidak sesuai di yarn.lock meskipun package.json tidak berubah:

  • perubahan pada versi benang di seluruh mesin memperbarui file kunci
  • dependensi git diperbarui bahkan jika package.json belum diperbarui, yang kemudian memperbarui lockfile

Kita juga harus mempertimbangkan sesuatu seperti flag --locked Cargo, yang dapat Anda gunakan di CI untuk mempercepat kegagalan build jika pengembang memperbarui package.json dan lupa memeriksa yarn.lock diperbarui

Semua 54 komentar

Saya setuju. Harus ada diskusi tentang mengapa yarn install menulis lockfile secara default di tempat pertama, karena tampaknya bertentangan dengan seluruh konsep lockfile. Mengapa memiliki lockfile jika tidak mengunci versi secara default?

Ada kasus untuk yarn install membuat file kunci jika tidak ada, yaitu ketika seseorang mengonversi proyek untuk menggunakan yarn , tetapi alasan untuk selalu menulisnya tidak jelas. Saya setuju dengan pendapat @bestander bahwa hanya tindakan bermutasi yang harus memperbarui lockfile secara default, yaitu add/upgrade/remove .

Haruskah ada cara untuk memodifikasi lockfile tanpa add/remove/upgrade ex: dalam skenario ketika Anda memutakhirkan Yarn dan menggunakan versi lockfile baru?

Saya kira opsinya bisa dibalik

yarn install --save-lockfile

Pada 17 Oktober 2016 pukul 18:53, James Ide [email protected] menulis:

Haruskah ada cara untuk memodifikasi file kunci tanpa menambah/menghapus/meningkatkan
mis: dalam skenario saat Anda memutakhirkan Benang dan menggunakan file kunci baru
Versi: kapan?


Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/570#issuecomment -254282256, atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ACBdWJLpdvqiwcBwqE4KB3x3f4oCn_nVks5q07YYgaJpZM4KSlSw
.

Saya juga bingung dengan ini. Apa alasan untuk perilaku default saat ini?

Afaik, tidak ada alasan kuat untuk perilaku default.
Idenya, saya kira, adalah untuk menjaga file kunci orang "hijau".

BTW PR dipersilahkan

Saya pikir alasannya adalah bahwa benang pada awalnya dirancang dengan satu perintah install yang dipecah menjadi install/add/upgrade

Jadi, untuk memeriksa apakah saya memahami ini dengan benar:

yarn menginstal semua dependensi dan juga memodifikasi file kunci. Di server CI Anda harus menggunakan yarn install --pure-lockfile ?
Mengapa lockfile diubah selama instalasi? Karena Anda tidak memutakhirkan apa pun... Benang seharusnya hanya menginstal paket-paket seperti yang dijelaskan dalam file kunci, bukan?

Terima kasih untuk penjelasannya!

Masalahnya adalah jika lockfile murni secara default maka orang akan lupa untuk memperbaruinya karena itu akan menjadi perintah yang terpisah.

@kittens Bukankah seharusnya file kunci hanya diperbarui setelah menambah/menghapus/memutakhirkan paket apa pun? Itu harus selalu memutakhirkan file kunci, serta instalasi awal.

Masalahnya adalah jika lockfile murni secara default maka orang akan lupa untuk memperbaruinya karena itu akan menjadi perintah yang terpisah

Itu menjadi masalah tergantung pada apa yang Anda anggap sebagai tujuan utama manajer paket.

Menurut pendapat saya, salah satu peran yang diisi oleh manajer paket adalah membuatnya semudah mungkin untuk memulai pengembangan sebuah proyek. yarn install seharusnya mendapatkan semua paket yang Anda butuhkan untuk mulai mengembangkan, tanpa kebingungan.

Dengan npm Saya memiliki banyak contoh pengembang bergabung dengan sebuah proyek, hanya untuk menemukan sebuah proyek tidak bekerja pada mesin mereka. Instance ini terjadi karena dependensi sementara yang menabrak versi ke versi dengan perubahan yang melanggar atau tidak mengikuti semver. Saya berharap yarn akan menyelesaikan masalah ini, tetapi jika kesimpulannya adalah bahwa semua pengembang pada suatu proyek harus menjalankan yarn install --pure-lockfile agar 100% yakin bahwa proyek tersebut akan dibangun, maka itu tidak kasus.

Peran lain dari manajer paket adalah memberikan kendali proyek atas dependensinya. Jika dibuat murni secara default, pengembang dapat melihat yarn outdated untuk melihat versi lama dan kemudian meninjau catatan perubahan, menghindari perubahan yang melanggar. Ini akan memberi pengembang kontrol penuh untuk hanya menabrak versi dalam jangka waktu rilis yang diberikan alih-alih melarang pengembang melakukan git commit -a untuk menghindari komit file kunci yang tidak disengaja.

Saya setuju dengan semua yang dikatakan @esphen . Saya terkejut bahwa perilaku murni bukanlah default di Benang – saya pikir konsistensi semacam ini adalah manfaat utama yang dimiliki Benang dibandingkan NPM. Ini harus menjadi alasan paling kuat untuk beralih dari NPM seperti yang saya lihat.

Benar-benar mengejutkan kami dengan merusak build setelah kami mulai menggunakan yarn selama beberapa hari. Sejujurnya saya berpikir --pure-lockfile adalah perilaku default setelah membaca banyak dokumentasi dan tentang bagaimana itu lebih baik daripada npm dengan shrinkwrap. Tolong jadikan default :)

@ide Bayangkan sebuah skenario di mana seseorang hanya menggunakan npm dan memperbarui package.json , bagaimana yarn.lock akan diperbarui?

Bisakah seseorang menulis skenario yang menyebabkan lockfile dimodifikasi secara tidak terduga? Perubahan ini adalah salah satu yang serius dan tidak membuat lockfile yang warga kelas kedua dengan mengharuskan pembaharuan untuk menjadi eksplisit yang berarti banyak overhead dalam mengingat apa yang menyebabkan operasi di dalamnya diperbarui dll

Info lebih lanjut tentang hal di atas: build kami memiliki skrip kopi dari Github sebagai subdependensi. coffeescript mendorong beberapa komit dan kami mendapatkan yarn.lock dimodifikasi dalam proses pembuatan kami dari menjalankan hanya yarn install :

diff --git a/foo/yarn.lock b/foo/yarn.lock
index ec667fa..bb1f6ae 100644
--- a/foo/yarn.lock
+++ b/foo/yarn.lock
@@ -930,9 +930,9 @@ code-point-at@^1.0.0:
   version "1.6.3"
   resolved "https://registry.yarnpkg.com/coffee-script/-/coffee-script-1.6.3.tgz#6355d32cf1b04cdff6b484e5e711782b2f0c39be"

-"coffee-script<strong i="8">@github</strong>:jashkenas/coffeescript":
+coffee-script@jashkenas/coffeescript:
   version "1.11.1"
-  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/887052de079b2f0af9f080031a00bb7544eaca08"
+  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/0d132318ce8f7116a436d97db1f2a5c8b1dedf28"

 [email protected]:
   version "0.3.0"

Bisakah seseorang menulis skenario yang menyebabkan lockfile dimodifikasi secara tidak terduga? Perubahan ini serius dan membuat lockfile menjadi warga negara kelas dua dengan mengharuskan pembaruan untuk itu secara eksplisit yang berarti banyak overhead dalam mengingat operasi apa yang mengakibatkannya diperbarui, dll.

Saya menganggap yarn install sebagai perintah yang membangun node_modules untuk saya.
Ini adalah kebalikan dari yarn add dan yarn remove yang memodifikasi package.json, yarn.lock dan cleanup node_modules.
Menentang add dan remove Saya menjalankan install 100 kali lebih sering terutama di CI di mana saya tidak pernah berharap memiliki efek samping.

Contoh ketika saya tidak mengharapkan hal-hal berubah:

  1. Saya menggunakan Benang 0.15.0, rekan tim saya menggunakan Benang 0.16.0.
    Karena 0.16.0 menambahkan spasi di antara entri di yarn.lock setiap kali saya menjalankan yarn install terhadap yarn.lock yang dihasilkan oleh rekan tim saya, saya mendapatkan file yarn.lock yang dimodifikasi yang perlu saya ingat untuk tidak melakukan.
    Dan sebaliknya.
  2. Alat build saya yang lain bergantung pada yarn.lock sebagai "sumber kebenaran" dari status node_modules. Jika itu berubah secara tak terduga, saya akan mendapatkan non determinisme di build saya

@anak kucing

Masalahnya adalah jika lockfile murni secara default maka orang akan lupa untuk memperbaruinya karena itu akan menjadi perintah yang terpisah.

Bayangkan sebuah skenario di mana seseorang hanya menggunakan npm dan memperbarui package.json, bagaimana yarn.lock akan diperbarui?

Jika kita berasumsi bahwa yarn install seharusnya tidak memperbarui yarn.lock , maka itu juga akan gagal jika yarn.lock tidak sinkron dengan package.json untuk menyoroti fakta bahwa yarn install --save-lockfile diperlukan untuk mengembalikan semuanya sinkron.

Pemasangan benang +1 seharusnya tidak mengubah yarn.lock

  1. Debugger adalah aplikasi oss. Kami ingin kontributor dapat memasang benang dan mendapatkan versi _good_. Kami telah meminta orang menginstal npm dan mengatakan itu rusak karena properti transitif. Dengan pemasangan benang, kontributor pemasangan benang dan tidak tahu apa yang harus dilakukan dengan perubahan kunci benang.

Saya tidak khawatir tentang memperbarui file kunci. Idealnya greenkeeper akan melakukan ini ketika deps berubah dan kita bisa menggabungkan perubahan file kunci itu.

Saya ingin memperbarui masalah ini dengan pemikiran terkini tentangnya. @kittens dan saya sama-sama berpikir bahwa --pure-lockfile seharusnya _not_ menjadi default karena beberapa alasan.

Ini dimulai dengan bagaimana orang menambah/menghapus/memperbarui dependensi. Meskipun ada perintah untuk itu, adalah praktik umum untuk memperbarui package.json secara manual baik dengan tangan atau dengan alat lain seperti Lerna .

Setelah Anda memodifikasi package.json manual, harapan di Yarn dan npm adalah ketika Anda menjalankan yang lain, instal _syncs_ dengan package.json . Dalam arti itu yarn install hampir bisa diganti namanya yarn sync .

Pada topik sinkronisasi, saat Anda menjalankan penginstalan dengan dependensi baru, Anda mengharapkan direktori node_modules mencerminkan perubahan tersebut. Karena yarn.lock bertindak sebagai asisten untuk node_modules Anda harus mengharapkannya tetap sinkron dengan cara yang sama.

package.json adalah sumber kebenaran tertinggi, itu adalah antarmuka Anda ke benang, ini adalah konfigurasi Anda dan itu satu-satunya hal yang harus Anda perhatikan. Di dunia yang ideal Anda cukup melakukan yarn.lock dan kemudian tidak perlu memikirkannya lagi.


Di samping catatan saya percaya banyak orang yang menyuarakan dukungan untuk masalah ini bingung tentang apa yang sebenarnya sedang dibahas di sini.

Menggunakan --pure-lockfile secara default tidak berarti bahwa Benang tidak memberikan hasil yang konsisten dan dapat diandalkan. package.json akan menghasilkan yarn.lock yang sama yang akan menghasilkan node_modules 100% setiap saat.

Saat Anda memperbarui package.json yarn.lock file node_modules diperbarui. Itu adalah tatanan yang sangat alami untuk hal-hal dan kita harus tetap seperti itu


Mengenai CI yang bisa mendapatkan dependensi yang berbeda ketika Anda telah memperbarui package.json tetapi belum menjalankan yarn install untuk menyinkronkan semua yang saya yakin seseorang akan memunculkan (walaupun saya tidak melihatnya sebagai masalah)-- saya dan orang lain telah berbicara dengan berbagai alat CI tentang mengintegrasikan Benang, kami dapat dengan mudah mendorong mereka untuk menggunakan --pure-lockfile secara default jika orang melihatnya sebagai masalah besar.


Jika kita membuat perubahan ini, itu akan memiliki dampak negatif yang jauh lebih sering ketika mengubah dependensi. Untuk alasan yang saya sebutkan, saya katakan kita harus menutup masalah ini.

@thejameskyle Saya akan sangat menghargai jika Anda dapat mengklarifikasi sesuatu:

  1. Pengembang memiliki package.json yang berisi ketergantungan "foo": "^1.0.0"
  2. Pengembang menjalankan yarn install . Paket foo saat ini versi 1.0.0 , sehingga membuat file yarn.lock yang terkunci di [email protected]
  3. Pengembang menambahkan yarn.lock ke Git.
  4. Pengembang menjalankan tes unit pada salinan repo lokal mereka, semuanya berfungsi dengan baik.
  5. Pengembang mendorong repo mereka ke CI (misalnya Travis).
  6. CI menjalankan yarn install , tetapi foo sekarang telah diperbarui ke versi 1.1.0 , jadi Yarn menginstal [email protected] dan menimpa yarn.lock dengan versi baru dari foo
  7. CI rusak karena foo mengalami perubahan yang mengganggu di versi 1.1.0

Berikut situasi serupa:

  1. Pengembang memiliki package.json yang berisi dependensi "foo": "^1.0.0" , yang dikunci sebagai [email protected] , dan yarn.lock disimpan di Git.
  2. Tes unit berfungsi dengan baik pada salinan repo lokal pengembang.
  3. Seorang kontributor mengkloning repo dengan maksud membuat modifikasi + permintaan tarik.
  4. Ketika kontributor menjalankan yarn install mereka mendapatkan versi [email protected] yang menyebabkan yarn.lock diperbarui.
  5. Sekarang build kontributor rusak karena foo mengalami perubahan besar pada versi 1.1.0

Saya pikir itu adalah jenis situasi yang dikhawatirkan kebanyakan orang.

Jadi, jika Anda dapat mengklarifikasi bahwa perilaku yarn install ini tidak memiliki masalah di atas, saya pikir itu akan menghilangkan sebagian besar ketakutan kita. :+1:

Tak satu pun dari situasi itu berlaku. Hanya karena ketergantungan telah diperbarui tidak berarti Anda akan mendapatkannya, hanya jika Anda telah membuat perubahan pada package.json .

Saya hanya akan menutup masalah ini karena sepertinya ini adalah satu-satunya kekhawatiran yang dimiliki orang, yang seperti yang saya katakan bukanlah skenario nyata. Masalah ini kemungkinan menyebabkan lebih banyak kebingungan.

Tetapi memang memiliki perilaku buruk jika ketergantungan sedang diinstal dari github, seperti yang saya laporkan di atas

@adamchainz Itu harus diperbaiki secara terpisah, kita dapat dengan mudah menguncinya ke komit

Tak satu pun dari situasi itu berlaku. Hanya karena ketergantungan telah diperbarui tidak berarti Anda akan mendapatkannya, hanya jika Anda telah membuat perubahan pada package.json .

@thejameskyle : Saya tidak yakin saya mengerti mengapa ini bukan skenario nyata. Bisa tolong jelaskan?

Bayangkan fungsi memoize di mana inputnya adalah package.json dan outputnya adalah yarn.lock .

  1. Pertama kali Anda melewatkan package.json itu membuat yarn.lock dan menyimpan hasilnya.
  2. Lain kali Anda menjalankan _that same_ package.json hasilnya akan sama persis karena di-cache.
  3. Ketika Anda mengubah package.json Anda telah membatalkan cache dan sekarang yarn.lock akan dihitung ulang.

Apa yang sedang kita bicarakan sekarang adalah menyingkirkan # 3 dan sebagai gantinya memperlakukan yarn.lock seolah-olah itu belum dibatalkan oleh package.json diubah. Yang akan sangat aneh untuk memiliki fungsi memoize dan akan menjadi perilaku yang sangat aneh untuk dimiliki Benang.

Apa yang terjadi pada sebuah paket dalam hal komit dan versi baru _harus_ tidak relevan (jika kita memiliki bug dengan komit git maka kita harus memperbaikinya secara terpisah, tetapi tidak terkait dengan masalah ini).

Ini lebih kompleks daripada yang saya bayangkan (setiap versi paket secara efektif "dikenal" satu per satu, mengubah versi satu paket tidak membatalkan sisanya), tetapi mudah-mudahan sekarang semua orang mengerti maksudnya.

@thejameskyle : Demi kejelasan (dan rasa ingin tahu), katakanlah saya memiliki proyek dengan file yarn.lock , dan seseorang menarik repositori. Tanpa menjalankan yarn install atau npm install , orang ini menambahkan ketergantungan baru ke file package.json dan kemudian menjalankan yarn install . Apakah file yarn.lock ada akan diabaikan sepenuhnya dalam kasus ini?

Ada banyak hal berbeda yang terjadi di sini yang ingin saya coba ungkap (tidak ada permainan kata-kata).

Pertama, orang-orang telah mengajukan sejumlah persyaratan berbeda yang menurut saya tidak kontroversial (dan yang membuat beberapa perilaku yang ada menjadi bug, yang akan segera saya selesaikan).

Dari laporan bug asli.

Konsistensi hilang ketika lockfile dimodifikasi tergantung pada lingkungan (versi benang yang saat ini diinstal).
Apa perilaku yang diharapkan?
Tidak menulis yarn.lock atau package.json saat melakukan instalasi yarn.
Untuk memperbarui yarn.lock gunakan peningkatan benang

Untuk lebih tepatnya, semantik yang diharapkan, menurut saya, adalah:

  • jika package.json tidak berubah sejak terakhir kali yarn.lock diubah, yarn.lock adalah sumber kebenaran dan tidak boleh diperbarui.
  • jika package.json telah berubah sejak terakhir kali, yarn.lock berubah, perbarui yarn.lock sehingga memenuhi package.json dan perbarui node_modules .
  • jika yarn update dijalankan, selesaikan kembali semua dependensi dan dapatkan versi terbaru dari semua yang memenuhi package.json .

Ini berarti bahwa ketika repositori pertama kali dikloning pada mesin , jika yarn.lock diperiksa, benang harus selalu memperlakukannya sebagai sumber kebenaran, tidak menghasilkan pembaruan ke yarn.lock , dan melompat langsung ke langkah pengambilan.

Sejauh ini bukan perilaku benang saat ini, saya percaya itu akan menjadi bug.


@esphen menulis:

Saya setuju. Harus ada diskusi tentang mengapa yarn install menulis lockfile secara default di tempat pertama, karena tampaknya bertentangan dengan seluruh konsep lockfile. Mengapa memiliki lockfile jika tidak mengunci versi secara default?

Saya pikir apa yang coba dikatakan ini adalah bahwa benang tidak boleh menulis file kunci baru jika yang sudah ada masih mutakhir. Saya setuju dengan itu.

Saya setuju dengan pendapat @bestander bahwa hanya tindakan bermutasi yang harus memperbarui file kunci secara default, yaitu tambah/tingkatkan/hapus.

Masalah utama di sini adalah apakah perubahan pada package.json akan menyebabkan yarn.lock diperbarui. Menurut pendapat saya, jika perubahan ke package.json tidak dipenuhi oleh yarn.lock , itu harus memperbarui yarn.lock .

Sebuah invarian penting dari sistem lockfile seperti benang adalah bahwa, dengan menggunakan alur kerja normal, pengembang dapat yakin bahwa paket yang benar-benar digunakan ketika mereka menjalankan aplikasi mereka cocok dengan versi yang ditentukan dalam package.json . Jika package.json dibiarkan tidak sinkron dengan yarn.lock , ini tidak akan benar, dan satu-satunya cara untuk mengetahuinya adalah agar pembaca manusia membaca yarn.lock dengan cermat

Cara terbaik bagi sebagian besar pengguna untuk berpikir tentang lockfile adalah bahwa itu adalah artefak dari benang yang sedang berjalan yang mewakili versi yang tepat dari semua paket yang digunakan untuk package.json . Dengan memeriksanya, kolaborator lain, CI, dan kode produksi dijamin untuk menggunakan versi yang sama.


@Guuz berkata:

Jadi, untuk memeriksa apakah saya memahami ini dengan benar:
benang menginstal semua dependensi dan juga memodifikasi file kunci. Pada server CI Anda harus menggunakan yarn install --pure-lockfile?

Pertanyaan ini menggemakan sentimen yang dibuat beberapa orang di utas ini.

Kargo memiliki bendera --locked yang mengatakan "jika package.json tidak puas dengan yarn.lock , itu adalah kesalahan yang sulit". Bundler memiliki flag serupa ( --frozen ), yang ditambahkan ketika Heroku mengadopsi Bundler, untuk memberikan kesalahan besar kepada orang-orang jika mereka membuat perubahan lokal pada Gemfile dan lupa memeriksa Gemfile.lock .

Idenya adalah bahwa selama pengembangan normal Anda, Anda ingin dapat membuat perubahan pada package.json dan memiliki yarn memastikan bahwa yarn.lock tetap sinkron (sekali lagi, untuk memastikan bahwa versi yang ditentukan di package.json selalu cocok dengan apa yang digunakan dalam praktik).

Tetapi ketika menerapkan, hampir selalu merupakan kesalahan untuk menyimpang, karena itu berarti Anda membuat perubahan ke package.json , menjalankan perintah yarn , dan lupa memeriksa yarn.lock . Ini berarti bahwa versi di package.json Anda tidak cocok dengan versi sebenarnya yang digunakan saat aplikasi dijalankan , yang menurut kami melanggar invarian dasar benang.


@esfen berkata:

Menurut pendapat saya, salah satu peran yang diisi oleh manajer paket adalah membuatnya semudah mungkin untuk memulai pengembangan sebuah proyek. Pemasangan benang sederhana harus mendapatkan semua paket yang Anda butuhkan untuk mulai mengembangkan, tanpa kebingungan yang terlibat.

Saya pikir ini tidak kontroversial.

Dengan npm saya memiliki banyak contoh pengembang bergabung dengan sebuah proyek, hanya untuk menemukan sebuah proyek tidak berfungsi di mesin mereka. Instance ini terjadi karena dependensi sementara yang menabrak versi ke versi dengan perubahan yang melanggar atau tidak mengikuti semver. Saya berharap benang akan menyelesaikan masalah ini, tetapi jika kesimpulannya adalah bahwa semua pengembang pada suatu proyek harus menjalankan yarn install --pure-lockfile agar 100% yakin bahwa proyek tersebut akan dibangun, maka bukan itu masalahnya.

Menjalankan yarn install --pure-lockfile akan berarti bahwa lockfile akan dihormati bahkan jika versi di dalam lockfile bertentangan dengan versi yang ditentukan dalam package.json . Ini seharusnya hanya muncul di tempat pertama jika pengembang lupa untuk memeriksa yarn.lock setelah membuat perubahan pada package.json .

Peran lain dari manajer paket adalah memberikan kendali proyek atas dependensinya. Jika dibuat murni secara default, pengembang dapat melihat benang usang untuk melihat versi usang dan kemudian meninjau catatan perubahan, menghindari perubahan yang melanggar. Ini akan memberi pengembang kontrol penuh untuk hanya menabrak versi dalam jangka waktu rilis yang diberikan alih-alih melarang pengembang melakukan git commit -a untuk menghindari komit lockfile yang tidak disengaja.

Jika package.json tidak berubah, menurut saya itu adalah bug jika yarn.lock diperbarui. Setidaknya satu kasus bug tampaknya ada di laporan asli:

lockfile dimodifikasi tergantung pada lingkungan (versi benang yang saat ini diinstal).

Saya pikir ini adalah kesalahan dan harus diperbaiki.

Kemudian di utas, @thejameskyle berkata:

Bayangkan sebuah fungsi memoize di mana inputnya adalah package.json dan outputnya adalah yarn.lock.

Itu persis model mental yang tepat, menurut saya (" yarn.lock dapat berubah jika dan hanya jika package.json berubah"), dan jika abstraksi bocor, kita harus memperbaikinya.


@adamchainz berkata:

Info lebih lanjut tentang hal di atas: build kami memiliki skrip kopi dari Github sebagai subdependensi. coffeescript mendorong beberapa komit dan kami mendapatkan yarn.lock yang dimodifikasi dalam proses pembuatan kami dari menjalankan hanya pemasangan benang

dan kemudian:

Tetapi memang memiliki perilaku buruk jika ketergantungan sedang diinstal dari github, seperti yang saya laporkan di atas

Masalahnya di sini adalah bahwa benang tidak memperlakukan git sha sebagai bagian dari versi terkunci dari dependensi git. Cargo dan Bundler keduanya memiliki konsep versi "tepat" yang diserialkan ke file kunci; untuk sumber git, versi "tepat" adalah SHA. Kemudian, ketika Anda membuat klon baru hanya dengan package.json dan yarn.lock dan menjalankan yarn , semua informasi yang diperlukan untuk mendapatkan kode yang Anda butuhkan ada di sana.

Saya harus mengakui bahwa saya melewatkan interaksi ini ketika meninjau kode git asli; ada beberapa pelacakan SHA dalam kode, tetapi yarn install tidak memastikan bahwa grafik ketergantungan terhidrasi menghormatinya.


TL;DR

Saya setuju dengan @thejameskyle dan @kittens bahwa yarn.lock harus disinkronkan dengan package.json secara otomatis, karena saya percaya bahwa pengguna harus dapat mengasumsikan bahwa versi yang ditentukan dalam package.json sejalan dengan apa yang digunakan saat aplikasi mereka dijalankan.

Namun, tampaknya ada beberapa bug yang menyebabkan churn yang tidak sesuai di yarn.lock meskipun package.json tidak berubah:

  • perubahan pada versi benang di seluruh mesin memperbarui file kunci
  • dependensi git diperbarui bahkan jika package.json belum diperbarui, yang kemudian memperbarui lockfile

Kita juga harus mempertimbangkan sesuatu seperti flag --locked Cargo, yang dapat Anda gunakan di CI untuk mempercepat kegagalan build jika pengembang memperbarui package.json dan lupa memeriksa yarn.lock diperbarui

@thejameskyle Terima kasih! :heart: Saya setuju dengan Anda dan @kittens bahwa yarn.lock harus diperbarui setelah mengubah package.json

@wycats Postingan yang sangat menyeluruh dan berwawasan seperti biasa. :+1: Saya setuju dengan Anda, dan saya juga menyukai gagasan tentang bendera --locked (atau yang serupa). Kita harus membuat masalah baru tentang itu.

Membuat #1568 untuk melacak masalah git SHA

@wycats , terima kasih atas ikhtisar yang mengungkap dan sangat berwawasan!

Ini berarti bahwa ketika repositori pertama kali dikloning pada mesin, jika yarn.lock diperiksa, yarn harus selalu memperlakukannya sebagai sumber kebenaran, tidak menghasilkan pembaruan pada yarn.lock, dan langsung melompat ke langkah pengambilan.
Sejauh ini bukan perilaku benang saat ini, saya percaya itu akan menjadi bug.

Itulah skenario mengapa masalah ini dibuka.
Kami memiliki beberapa versi aktif Benang di perusahaan dan pada skala kami, saya tidak berpikir kami akan dapat membuat pembaruan atom di mana-mana.
Dibangun di atas yarn 0.13, 0.14 dan 0.15 memperkenalkan sedikit variasi dalam file yarn.lock meskipun package.json sinkron.
Hal ini menyebabkan beberapa masalah, misalnya build Buck melambat karena perubahan pada pohon sumber membuat cache menjadi tidak valid.
Hal ini menyebabkan saya dan beberapa tim bekerja beberapa jam.

@thejameskyle , terima kasih telah berbagi pendapat Anda.
Saya tidak menganggap skenario package.json tidak sinkron dengan yarn.lock, agar adil. Dan Anda memiliki poin yang valid.

Namun seperti yang ditunjukkan @wycats , laporan bug asli valid.
Memperbaiki ini penting untuk memiliki build yang valid dan saya akan membuka kembali masalah dengan maksud untuk menghasilkan solusi yang memuaskan semua pihak yang berkepentingan.

@wycats

Untuk lebih tepatnya, semantik yang diharapkan, menurut saya, adalah:

  • jika package.json tidak berubah sejak terakhir kali yarn.lock diubah, yarn.lock adalah sumber kebenaran dan tidak boleh diperbarui.
  • jika package.json telah berubah sejak terakhir kali, yarn.lock berubah, perbarui yarn.lock sehingga memenuhi package.json dan perbarui node_modules .
  • jika yarn update dijalankan, selesaikan kembali semua dependensi dan dapatkan versi terbaru dari semua yang memenuhi package.json .

Ini berarti bahwa ketika repositori pertama kali dikloning pada mesin , jika yarn.lock diperiksa, benang harus selalu memperlakukannya sebagai sumber kebenaran, tidak menghasilkan pembaruan ke yarn.lock , dan melompat langsung ke langkah pengambilan.

Ini adalah semantik yang kami ikuti yang saya tambahkan di #364.

@bestander Anda terlibat dalam PR (#364) yang menempatkan heuristik ini pada tempatnya. Perubahan tambahan apa yang Anda usulkan?

Masalah ini sangat luas dan kami telah sepakat bahwa --pure-lockfile tidak akan menjadi default dan kami akan mengikuti heuristik yang digariskan oleh @wycats. Jika masalah ini akan tetap terbuka maka judul harus mencerminkan masalah saat ini dengan perilaku ini.

@kittens terdengar bagus, saya akan memperbarui masalah ini.
Atau mungkin saya harus membuka yang baru terkait dengan menginstal mengubah file kunci ketika package.json tidak berubah

Bisakah kita pindah ke masalah baru? Komentar ini di sini hanya dapat disimpan sebagai arsip

Kedengarannya bagus, @thejameskyle , saya akan membuat edisi baru hari ini dan menautkannya di sini

Membuat masalah fokus baru https://github.com/yarnpkg/yarn/issues/1576

akan menarik untuk memiliki opsi untuk membuat yarn install gagal jika paket di package.json tidak ada di yarn.lock, mis. gagal jika ada paket yang tidak terkunci

Menambahkan klarifikasi yang masih ambigu bagi saya setelah membaca di atas:

tldr; Perubahan yang tidak terkait dalam package.json tidak akan memperbarui paket ke versi terbaru yang kompatibel dengan semver package.json berubah.

Berdasarkan beberapa kata di atas, kedengarannya seperti yarn.lock -cache dikunci pada hash package.json , dan dengan demikian terdengar seperti yarn.lock akan ditulis (diperbarui / cache tidak valid ) pada setiap perubahan ke package.json , yang akan bermasalah karena perubahan yang tidak terkait (yaitu, perbarui ke "description" atau dependensi lain) dapat menyebabkan versi yarn.lock dependensi tersebut diperbarui ke versi yang lebih baru dalam semver package.json sama.

Namun, saya memverifikasi bahwa entri yarn.lock sebuah paket hanya ditulis ketika semver package.json sesuai diperbarui (bahkan jika semver baru kompatibel dengan versi yarn.lock , dan akibatnya tidak akan memerlukan pembaruan versi).

Sebagai contoh,

  • Katakanlah yarn add lodash@^4.17.1 menginstal [email protected]
  • Nanti, [email protected] tersedia.
  • benang akan terus menginstal [email protected]
  • Kecuali/Sampai versi lodash diubah dalam package.json (atau yarn add/upgrade/remove dijalankan secara khusus terhadap lodash).

Remah roti #1576

BTW jika Anda bersedia berkontribusi pada dokumen dengan artikel kecil seperti ini, itu akan sangat bagus untuk komunitas.
Tim inti sibuk memperbaiki masalah dan menambahkan fitur baru dan diharapkan dan dihargai jika komunitas membantu menjaga dokumentasi

@CrabDude terima kasih telah berbagi klarifikasi Anda.

Maksud Anda - dalam contoh Anda di atas - bahwa hanya lodash dan dependensinya sendiri yang akan memperbarui versi kuncinya di yarn.lock ? misalnya bahkan jika ketergantungan lain dapat memiliki versi kunci baru maka itu tidak akan diperbarui pada saat yang sama?

Atau contoh kedua: Katakanlah yarn.lock sudah sangat usang, dan pengguna menjalankan yarn add untuk menambahkan ketergantungan baru ke package.json. Apakah semua paket usang lainnya sekarang akan diperbarui dalam yarn.lock , atau akan tetap sama?

@rarkins

Maksud Anda - dalam contoh Anda di atas - bahwa hanya lodash dan dependensinya sendiri yang akan diperbarui versi kuncinya di yarn.lock?

Ya. Ini tampaknya ditegakkan dalam contoh saya.

Apakah semua paket usang lainnya sekarang diperbarui di yarn.lock, atau akan tetap sama?

Tampaknya pohon ketergantungan non- lodash / entri kunci paket tidak akan diperbarui; hanya sub-dependensi lodash akan menjadi.

Dari sudut pandang saya, masing-masing diinginkan dan diharapkan.

Kata Pengantar : Saya suka benang. Tapi itu membuatku frustrasi tanpa akhir.

Di perusahaan saya, yarn install mengubah lockfile secara konstan di berbagai mesin (masing-masing menjalankan versi yang sama), meskipun tidak pernah mengubah package.json . Dan ketika kami melakukannya, kami memperbarui menggunakan yarn add . Ini menjengkelkan karena CI memverifikasi bahwa status git bersih setelah build untuk memastikan kami tidak lupa melakukan hal-hal seperti memeriksa file kunci, dan itu sering berubah.

Harapan saya tentang benang adalah bahwa itu akan memastikan node_modules identik di semua mesin _secara default_. Tidak dengan bendera tambahan. Itu akan memprioritaskan kebenaran daripada kenyamanan. Jika saya menginginkan ketidakpastian, saya dapat menggunakan npm secara langsung. Ketika sebuah file berubah, itu adalah sinyal bagi saya bahwa ada sesuatu yang mengubahnya dan saya harus menelitinya. Seharusnya tidak berubah.

Pertanyaan

  • Apakah dikatakan bahwa meskipun lockfile diubah, isi node_modules akan selalu identik dengan ketika dibuat? Saya tidak percaya ini masalahnya tetapi jika ya, maka saya memahami kebingungan di utas ini - itu berarti bahwa benang melakukan hal yang benar meskipun kelihatannya tidak.
  • Ketika package.json berubah, file kunci dibuat ulang. Tidak bisakah itu secara tidak sengaja mengubah banyak dependensi tergantung pada keadaan node_modules programmer tertentu? Benang harus menentukan delta dan mencoba untuk mempertahankan kunci yang ada sebaik mungkin (jika belum).
  • Mengapa yarn add menentukan versi dalam package.json dengan ^ ? Sekali lagi, saya mengerti janji benang adalah untuk membekukan dependensi.

Bug Terkait

  • Ketika paket acak dihapus di node_modules , yarn install mengatakan sukses tanpa menginstal ulang. Ketika banyak dari mereka hilang, itu menginstal ulang mereka. npm sedikit lebih teliti dalam hal ini.
  • Lockfile cenderung dibuat ulang jika Anda menghapus node_modules dan melakukan instalasi bersih (yang secara harfiah kebalikan dari apa yang Anda harapkan - saya berharap untuk menginstal persis apa yang ada di lockfile dan sama sekali tidak melakukan apa pun)
  • Jika Anda menghapus lockfile tanpa menyentuh package atau node_modules setelah instalasi bersih, yarn akan meregenerasinya dan biasanya sangat berbeda dari versi sebelumnya. Ini seperti kompiler yang menghasilkan kode berbeda setiap kali Anda menjalankannya meskipun tidak mengubah apa pun.

Secara keseluruhan, yarn membuat pemasangan lebih cepat, tetapi tampaknya gagal pada kompetensi (dalam) intinya: Versi pembekuan, secara konsisten, secara default. Saya tidak membutuhkan kemudahan yang membantu saya memulai proyek saya, saya perlu bantuan untuk mempertahankannya dalam tim besar selama bertahun-tahun. Pemrogram cerdas dan disengaja, ketika mereka menginginkan perubahan, mereka akan bertanya secara eksplisit.

Lockfile yang terus berubah tidak menanamkan kepercayaan diri dan selalu merepotkan. Saya lebih suka peringatan dan kesalahan bahwa package.json tidak cocok dengan lockfile, bahwa lockfile tidak cocok dengan node_modules, bahwa versi yang dikunci tidak ada lagi, dll., sehingga menghentikan build saya mati di jalurnya dan saya bisa membuat keputusan yang disengaja tentang ketergantungan saya.

@jspiro , terima kasih telah menulis ini.
Ada beberapa isu yang diangkat di sini.
Akan lebih baik untuk membuka setiap masalah secara terpisah jika tidak, mereka akan hilang di komentar.

Apakah Anda menggunakan Benang versi terbaru?
Pada 0,18-0,19 kami tidak melihat modifikasi pada file yarn.lock antar mesin.

Pertanyaan:

Apakah dikatakan bahwa meskipun lockfile diubah, isi node_modules akan selalu identik dengan ketika dibuat? Saya tidak percaya ini masalahnya tetapi jika ya, maka saya memahami kebingungan di utas ini - itu berarti bahwa benang melakukan hal yang benar meskipun kelihatannya tidak.

Dev dan dependensi opsional dapat diabaikan untuk file kunci yang sama.
Tetapi yang terinstal bing, kecuali untuk paket khusus platform, node_modules harus memiliki paket yang identik di tempat yang sama.

Ketika package.json berubah, lockfile dibuat ulang. Tidak bisakah itu secara tidak sengaja mengubah banyak dependensi tergantung pada keadaan node_modules programmer tertentu? Benang harus menentukan delta dan mencoba untuk mempertahankan kunci yang ada sebaik mungkin (jika belum).

Itu adalah permintaan fitur yang bagus, akan senang melihat PR untuk itu.

Mengapa yarn add menentukan versi di package.json dengan ^? Sekali lagi, saya mengerti janji benang adalah untuk membekukan dependensi.

Itu mencerminkan perilaku npm.
Anda dapat melakukan yarn add [email protected] atau yarn add is-array --exact untuk versi yang tepat.
Mungkin di beberapa titik kita harus membuat versi yang tepat default, ini bisa menjadi diskusi di RFC.

Ketika paket acak dihapus di node_modules, yarn install mengatakan sukses tanpa menginstal ulang. Ketika banyak dari mereka hilang, itu menginstal ulang mereka. npm sedikit lebih teliti dalam hal ini.

Benang menjalankan pemeriksaan dangkal cepat secara default.
Melakukan pemeriksaan yang lebih dalam akan lebih lambat tetapi kami sedang mengerjakannya, saya punya ide bagaimana kami bisa melakukan pemeriksaan mendalam yang cepat.
Anda tidak seharusnya menyentuh file di node_modules, memverifikasi setiap file untuk modifikasi akan menghasilkan pengalaman instalasi yang sangat lambat.
Jika Anda ingin melewati pemeriksaan dangkal, hapus file node_modules/.yarn-integrity sebelum instalasi. Ini tidak resmi dan dapat berubah.
Cara resmi adalah dengan menjalankan yarn install --force , itu akan memaksa instalasi penuh tetapi akan menulis ulang yarn.lock sebagai efek samping.

Lockfile cenderung dibuat ulang jika Anda menghapus node_modules dan melakukan instalasi bersih (yang secara harfiah kebalikan dari apa yang Anda harapkan - saya berharap untuk menginstal persis apa yang ada di lockfile dan sama sekali tidak melakukan apa pun)

Sudah lama tidak melihat ini.
Buka masalah dan cc saya jika ini dapat direproduksi.

Jika Anda menghapus lockfile tanpa menyentuh package atau node_modules setelah instalasi bersih, yarn akan meregenerasinya dan biasanya sangat berbeda dari versi sebelumnya. Ini seperti kompiler yang menghasilkan kode berbeda setiap kali Anda menjalankannya meskipun tidak mengubah apa pun.

Setelah beberapa waktu, versi baru dependensi transitif mungkin telah dirilis.
Karena itu struktur node_modules dapat berubah secara signifikan karena logika pengangkatan.
Itu berfungsi seperti yang dirancang.
Ada perintah import datang https://github.com/yarnpkg/yarn/pull/2580.
Itu akan memungkinkan Anda membuat file kunci dari node_modules yang ada.

@jspiro , Benang adalah proyek yang digerakkan oleh komunitas muda, PR Anda untuk membuatnya bekerja lebih baik untuk Anda dipersilakan.

Adakah peluang untuk mendapatkan setidaknya opsi untuk mengatur perilaku default yang diinginkan?

Saat ini kami sedang memperbaiki masalah ini https://github.com/yarnpkg/yarn/issues/3490 , terkadang yarn install dapat menyebabkan lockfile dioptimalkan yang bukan merupakan perilaku yang diharapkan dan kami akan memperbaikinya.
Itu mungkin alasan mengapa Anda meminta perubahan ini, jika tidak, file yarn.lock akan berubah hanya jika Anda membuat perubahan pada package.json secara manual.

Anda dapat mengatur --pure-lockfile/--frozen-lockfile menjadi true di .yarnrc dan itu akan ditambahkan ke perintah install secara default:

--install.pure-lockfile true

Masalah saya adalah jika saya tidak menggunakan pure-lockfile saya mendapatkan versi dependensi yang salah diinstal. Ini tidak terkait dengan perubahan yarn.lock yang tidak diinginkan

Bisakah Anda mengirimkan masalah dengan langkah-langkah repro?
Kami akan menyelesaikannya

Saya digigit oleh ini juga ketika package.json dan yarn.lock tidak sinkron karena pengembang keliru menambahkan ketergantungan melalui npm install --save alih-alih yarn add .

Saya tidak setuju bahwa pure-lockfile harus menjadi default dan berpendapat bahwa frozen-lockfile seharusnya menjadi default untuk yarn install .

Karena frozen-lockfile menghasilkan pesan kesalahan jika yarn.lock dan package.json tidak sinkron. Oleh karena itu, frozen-lockfile sangat membantu pada mesin build (yaitu jenkins) karena akan menandai build tersebut, seperti yang diharapkan, sebagai kegagalan.

Terserah pengembang untuk memutuskan versi mana yang akan ditambahkan dalam package.json / yarn.lock.

Default yarn install menguntungkan hanya akan mengambil versi terbaru dari dependensi yang belum dikunci, dan menulis versi yang diperbarui yarn.lock , yang tidak akan pernah menjadi bagian dari proyek. Oleh karena itu, memungkinkan jeda build di masa mendatang karena versi yang tidak terduga. Itulah alasan kami memiliki lockfile untuk memulai.

Intinya harus:

Hanya perintah seperti add , remove , dan upgrade harus mengubah yarn.lock .

install seharusnya hanya melakukan itu, yaitu menginstal dependensi dalam versi terkuncinya atau gagal jika mendeteksi ketidakcocokan antara package.json dan yarn.lock . (Satu-satunya pengecualian adalah jika tidak ada yarn.lock di tempat pertama. Kemudian, dan hanya kemudian, ia dapat membuat satu, namun tidak pernah menyentuhnya lagi.)

Oleh karena itu, frozen-lockfile sangat membantu pada mesin build (yaitu jenkins) karena build tersebut akan gagal.

Saya pikir kita dapat mengaktifkan ini secara otomatis ketika kita mendeteksi bahwa kita berada dalam mode CI?

@BYK Saya tidak menyadari masalah ini ditutup sebelum menambahkan di sini. Haruskah saya membuka yang baru atau dapatkah ini dibuka kembali?

Saya akan mengatakan buka yang baru ️

Saya setuju dengan @thejameskyle dan @kittens bahwa yarn.lock harus disinkronkan dengan package.json secara otomatis

Tidak yakin apakah ini telah dikatakan, tetapi untuk berjaga-jaga: Anda tidak perlu membatalkan seluruh yarn.lock ketika sesuatu di package.json berubah. Anda hanya dapat membatalkan dependensi hanya paket yang dimodifikasi di dalam package.json. Fe jika Anda hanya memperbarui TypeScript, pada dependensi TypeScript perlu dimodifikasi (dengan pertimbangan sehubungan dengan paket lain yang tidak berubah).

Apakah halaman ini membantu?
0 / 5 - 0 peringkat