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
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:
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.@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
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:
package.json
yang berisi ketergantungan "foo": "^1.0.0"
yarn install
. Paket foo
saat ini versi 1.0.0
, sehingga membuat file yarn.lock
yang terkunci di [email protected]
yarn.lock
ke Git.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
foo
mengalami perubahan yang mengganggu di versi 1.1.0
Berikut situasi serupa:
package.json
yang berisi dependensi "foo": "^1.0.0"
, yang dikunci sebagai [email protected]
, dan yarn.lock
disimpan di Git.yarn install
mereka mendapatkan versi [email protected]
yang menyebabkan yarn.lock
diperbarui.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
.
package.json
itu membuat yarn.lock
dan menyimpan hasilnya.package.json
hasilnya akan sama persis karena di-cache.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:
package.json
tidak berubah sejak terakhir kali yarn.lock
diubah, yarn.lock
adalah sumber kebenaran dan tidak boleh diperbarui.package.json
telah berubah sejak terakhir kali, yarn.lock
berubah, perbarui yarn.lock
sehingga memenuhi package.json
dan perbarui node_modules
.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:
package.json
belum diperbarui, yang kemudian memperbarui lockfileKita 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 kaliyarn.lock
diubah,yarn.lock
adalah sumber kebenaran dan tidak boleh diperbarui.- jika
package.json
telah berubah sejak terakhir kali,yarn.lock
berubah, perbaruiyarn.lock
sehingga memenuhipackage.json
dan perbaruinode_modules
.- jika
yarn update
dijalankan, selesaikan kembali semua dependensi dan dapatkan versi terbaru dari semua yang memenuhipackage.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 keyarn.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,
yarn add lodash@^4.17.1
menginstal [email protected]
[email protected]
tersedia.[email protected]
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
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).yarn add
menentukan versi dalam package.json
dengan ^
? Sekali lagi, saya mengerti janji benang adalah untuk membekukan dependensi.Bug Terkait
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.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).
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.
Untuk lebih tepatnya, semantik yang diharapkan, menurut saya, adalah:
package.json
tidak berubah sejak terakhir kaliyarn.lock
diubah,yarn.lock
adalah sumber kebenaran dan tidak boleh diperbarui.package.json
telah berubah sejak terakhir kali,yarn.lock
berubah, perbaruiyarn.lock
sehingga memenuhipackage.json
dan perbaruinode_modules
.yarn update
dijalankan, selesaikan kembali semua dependensi dan dapatkan versi terbaru dari semua yang memenuhipackage.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 keyarn.lock
, dan melompat langsung ke langkah pengambilan.Sejauh ini bukan perilaku benang saat ini, saya percaya itu akan menjadi bug.
@esphen menulis:
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.
Masalah utama di sini adalah apakah perubahan pada
package.json
akan menyebabkanyarn.lock
diperbarui. Menurut pendapat saya, jika perubahan kepackage.json
tidak dipenuhi olehyarn.lock
, itu harus memperbaruiyarn.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
. Jikapackage.json
dibiarkan tidak sinkron denganyarn.lock
, ini tidak akan benar, dan satu-satunya cara untuk mengetahuinya adalah agar pembaca manusia membacayarn.lock
dengan cermatCara 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:
Pertanyaan ini menggemakan sentimen yang dibuat beberapa orang di utas ini.
Kargo memiliki bendera
--locked
yang mengatakan "jikapackage.json
tidak puas denganyarn.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 padaGemfile
dan lupa memeriksaGemfile.lock
.Idenya adalah bahwa selama pengembangan normal Anda, Anda ingin dapat membuat perubahan pada
package.json
dan memiliki yarn memastikan bahwayarn.lock
tetap sinkron (sekali lagi, untuk memastikan bahwa versi yang ditentukan dipackage.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 perintahyarn
, dan lupa memeriksayarn.lock
. Ini berarti bahwa versi dipackage.json
Anda tidak cocok dengan versi sebenarnya yang digunakan saat aplikasi dijalankan , yang menurut kami melanggar invarian dasar benang.@esfen berkata:
Saya pikir ini tidak kontroversial.
Menjalankan
yarn install --pure-lockfile
akan berarti bahwa lockfile akan dihormati bahkan jika versi di dalam lockfile bertentangan dengan versi yang ditentukan dalampackage.json
. Ini seharusnya hanya muncul di tempat pertama jika pengembang lupa untuk memeriksayarn.lock
setelah membuat perubahan padapackage.json
.Jika
package.json
tidak berubah, menurut saya itu adalah bug jikayarn.lock
diperbarui. Setidaknya satu kasus bug tampaknya ada di laporan asli:Saya pikir ini adalah kesalahan dan harus diperbaiki.
Kemudian di utas, @thejameskyle berkata:
Itu persis model mental yang tepat, menurut saya ("
yarn.lock
dapat berubah jika dan hanya jikapackage.json
berubah"), dan jika abstraksi bocor, kita harus memperbaikinya.@adamchainz berkata:
dan kemudian:
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
danyarn.lock
dan menjalankanyarn
, 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 denganpackage.json
secara otomatis, karena saya percaya bahwa pengguna harus dapat mengasumsikan bahwa versi yang ditentukan dalampackage.json
sejalan dengan apa yang digunakan saat aplikasi mereka dijalankan.Namun, tampaknya ada beberapa bug yang menyebabkan churn yang tidak sesuai di
yarn.lock
meskipunpackage.json
tidak berubah:package.json
belum diperbarui, yang kemudian memperbarui lockfileKita juga harus mempertimbangkan sesuatu seperti flag
--locked
Cargo, yang dapat Anda gunakan di CI untuk mempercepat kegagalan build jika pengembang memperbaruipackage.json
dan lupa memeriksayarn.lock
diperbarui