Yarn: Ide: mendukung package-lock.json dari npm 5

Saya berharap ini akan berubah di masa depan, tetapi... Apa praktik terbaik saat ini untuk menangani package-lock.json dan yarn.lock?

Ini adalah opsi yang saya lihat ...

1. Jangan, dan hanya dukung salah satunya di proyek Anda.
2. Semua orang secara manual menyinkronkannya untuk setiap perubahan ketergantungan
3. Gunakan beberapa alat untuk membangun kembali salah satu kunci ketika Anda mengubah yang lain. _(Saya berharap untuk yang ini :)_
4. Makan saja rasa sakitnya dan tunggu?

Saya akan memilih opsi 1 atau 4.. menyimpan banyak file untuk sinkronisasi yang sama membosankan dan rawan kesalahan.
Di sisi lain, kelemahan memilih untuk mendukung salah satu dari keduanya adalah Anda agak memaksa pengguna Anda untuk menggunakan benang atau npm, tetapi saya pikir ini akan kurang berbahaya daripada paket yang berbeda untuk manajer paket yang berbeda.

Jadi proyek kami menggunakan file package-lock.json atau yarn.lock, opsi pertama.

Di tempat kerja, kami saat ini berada dalam situasi aneh berikut:

• menggunakan benang untuk 95% dari CI kami, tetapi satu langkah menggunakan npm, karena itu adalah satu-satunya cara kami dapat membuatnya bekerja di dalam buruh pelabuhan.
• karena kami tidak tahu cara menyinkronkan file, kami memutuskan untuk .gitignore package-lock.json untuk saat ini, karena versi minimal npm kami adalah LTS, yang toh tidak mendukung ti.
• kami akan segera (berhari-hari atau berminggu-minggu) meningkatkan untuk menggunakan node v8 dan npm v5 sebagai versi minimal, maka kami mungkin beralih ke hanya menggunakan/mendukung package-lock.json dan .gitignore yarn.lock, jika tidak ada opsi untuk menyinkronkannya .

Pendekatan berikut akan bekerja untuk kita:
A) benang menggunakan nilai dari package-lock.json untuk menginstal
B) yarn menggunakan nilai dari package-lock.json untuk membuat/memperbarui yarn.lock
C) alat tambahan untuk membuat+sync yarn.lock dari package-lock.json

Dalam kasus packager umum, Benang berpotensi digunakan untuk Packagist (ada prototipe yang beredar), dan mungkin bahkan CocoaPods, selain NPM. Proyek PHP, misalnya, mungkin memiliki composer.lock dan package.json untuk mengelola skrip NPM. Mungkin bersandar terlalu jauh ke dalam perilaku penguncian NPM membatasi beberapa kemungkinan masa depan untuk ekstensibilitas packager ini?

Jika yarn mulai mengelola jenis dependensi lain, itu masih selalu diharapkan untuk menghasilkan versi dependensi yang sama persis seperti manajer lain dari dependensi yang sama. ( yarn install atau npm install akan memberi Anda dependensi yang identik).

Jadi saya akan berpikir itu harus selalu mengikuti standar yang berlaku untuk jenis ketergantungan. Yaitu, untuk dependensi PHP harus menggunakan composer.lock , untuk NPM harus menggunakan package-lock.json .

Cara saya melihatnya Komposer adalah Pear sebagai Benang adalah untuk NPM. Bedanya NPM menggunakan NPM dimana Composer menggunakan Packagist. Jika Benang mempertahankan standarnya sendiri, kami dapat mencegah kemacetan dan kerumitan perkakas yang dapat melumpuhkan Benang dan menghambat momentum maju di pemaket lainnya.

Apakah naif untuk berpikir bahwa 80% case dapat diringkas menjadi satu packager, dengan packager tambahan untuk menambah nilai 20% dan use case tambahan? Tampaknya pendekatan semacam itu dapat melayani mayoritas sambil membatasi kompleksitas, memungkinkan inovasi di pinggiran yang kemudian dapat digeneralisasi dan ditarik ke dalam Benang saat proposisi nilai menjadi jelas dalam jangka panjang.

Tampaknya bagi saya inilah yang sedang dilakukan NPM sendiri saat ini. Saya bisa saja salah.

Ya saya setuju, Benang ingin mempertahankan ruang independennya sejauh mungkin, sehingga memiliki fleksibilitas untuk memberikan pengalaman yang lebih baik. Itulah sebabnya, misalnya, CLI Benang sengaja tidak kompatibel dengan NPM.

Namun, saya pikir file kunci berada di luar ruang di mana Benang dapat mempertahankan independensinya secara wajar. package-lock.json dan composer.lock dikomit ke repositori , bersama package.json dan composer.json . Ini bukan file khusus alat, melainkan file khusus proyek yang menentukan versi dependensi persis yang dijamin dapat digunakan oleh proyek.

Ketika NPM tidak menawarkan kemampuan untuk mengunci dependensi, masuk akal bagi Yarn untuk membuat yarn.lock . Tapi sekarang NPM telah mendefinisikan cara standar bagi proyek untuk menentukan versi ketergantungan eksplisit yang diketahui bekerja dengan mereka, dan selanjutnya dinamai mirip dengan package.json yang Yarn sudah andalkan, itu tidak membuat masuk akal bagi Benang untuk terus berjalan dengan caranya sendiri.

Agar Benang menjadi alat yang berguna, ia harus memungkinkan pengembang untuk mengikuti model standar dalam proyek mereka, sehingga proyek dapat tetap tidak menggunakan alat. Karena itulah Yarn dibuat di atas package.json dan bukan file ketergantungannya sendiri yang terpisah.

tanda

Utas Stack Overflow membahas salah satu masalah akibat memiliki 2 jenis file kunci:

https://stackoverflow.com/questions/44552348/should-i-commit-yarn-lock-and-package-lock-json-files

Telah melakukan beberapa bacaan hari ini, menemukan ini di npm docs.

Satu detail kunci tentang package-lock.json adalah bahwa itu tidak dapat dipublikasikan, dan itu akan diabaikan jika ditemukan di tempat lain selain paket tingkat atas.

https://docs.npmjs.com/files/package-lock.json

Mungkin ini adalah pengetahuan umum, tetapi saya pasti berpikir npm akan menggunakan file kunci dalam dependensi. Saya pikir itu mungkin menarik bagi orang lain yang membahas masalah ini, karena saya sebagian besar khawatir tentang orang yang menginstal paket saya dengan npm 5 karena kami tidak menggunakan kunci paket (kami menggunakan Benang sebagai gantinya).

Dari membaca beberapa dokumentasi tentang Renovasi, tampaknya masuk akal bahwa ia tidak menggunakan kunci paket dalam dependensi untuk menghindari node_modules yang membengkak dan masalah dengan menginstal dua versi paket yang terpisah.

Alasan kedua untuk menggunakan rentang berlaku untuk "perpustakaan" yang diterbitkan sebagai paket npm dengan maksud agar mereka digunakan/dibutuhkan() oleh paket lain. Dalam hal ini, biasanya merupakan ide yang buruk untuk menyematkan semua dependensi Anda karena itu akan memperkenalkan rentang sempit yang tidak perlu (satu rilis!) Dan menyebabkan sebagian besar pengguna paket Anda mengasapi node_modules mereka dengan duplikat.

Misalnya, Anda mungkin telah menyematkan foobar ke versi 1.1.0 dan penulis lain menyematkan foobarnya ke ketergantungan ke 1.2.2. Setiap pengguna dari kedua paket Anda akan berakhir dengan npm yang mencoba menginstal dua versi foobar yang terpisah, yang bahkan mungkin tidak berfungsi.

https://renovateapp.com/docs/deep-dives/dependency-pinning

Mungkin ini adalah pengetahuan umum, tetapi saya pasti berpikir npm akan menggunakan file kunci dalam dependensi.

@ryansmith94 perilaku ini di package-lock.json meniru perilaku yang sama persis di yarn.lock :

Saat Anda menerbitkan paket yang berisi yarn.lock, setiap pengguna perpustakaan itu tidak akan terpengaruh olehnya. Saat Anda menginstal dependensi di aplikasi atau pustaka Anda, hanya file yarn.lock Anda sendiri yang dihormati. Lockfiles dalam dependensi Anda akan diabaikan.

Terima kasih @nottrobin , senang mengetahuinya

Dapatkah seseorang dari kontributor inti benang mengomentari masalah ini? Saya akan sangat tertarik untuk mendengar pendapat mereka. :v:

@nicojs Saya menyebutkannya di Discord sebelum saya menjawab di sini, jika saya ingat dengan benar, mereka tidak punya waktu untuk memeriksanya dengan benar, tetapi ingin melakukannya. Saya berasumsi saya sedang berbicara dengan kontributor inti di saluran dukungan.

Dari komentar Irlandia di

1. Gunakan beberapa alat untuk membangun kembali salah satu kunci ketika Anda mengubah yang lain. (Saya berharap untuk yang ini :)

Jadi siapa yang memiliki alat yang dapat mereka bagikan?

Saya telah menggunakan urutan perintah ini untuk menyinkronkan perubahan yarn.lock ke package-lock.json tanpa pengeditan manual.

# clean up
rm -rf node_modules

# remove previous if exists
rm package-lock.json

# create node_modules tree according to yarn.lock file
yarn install

# generate lock file for currently installed node_modules tree
npm shrinkwrap

# rename shrinkwrap to lock
mv npm-shrinkwrap.json package-lock.json

# adds network metadata to package-lock.json (resolved and integrity sha-1)
npm install

Mungkin itu akan membantu seseorang ...

Saya tidak mengerti mengapa ada orang yang menggunakan benang di atas npm mengetahui mereka sangat tidak konsisten. Kami benar-benar tidak membutuhkan file kunci lain.

Saya tidak percaya bahwa pada tahun 2017 kami sedang berupaya menyinkronkan dua file kunci yang terpisah! Ini seharusnya tidak diperlukan sama sekali, dan terlebih lagi, kita seharusnya tidak berpikir untuk melakukan hal seperti itu!

@revolter Bisakah Anda terus berdiskusi tentang keadaan ekosistem dan seruan frustrasi terbatas misalnya reddit atau Twitter? Kemudian masalah ini dapat tetap fokus pada apakah dan bagaimana menerapkan fitur ini, dan mereka yang berlangganan hanya akan menerima pemberitahuan email tentang itu. Terima kasih!

@ahz Mengapa Anda menggunakan npm-shrinkwrap ? Bukankah inti dari utas ini bahwa NPM 5 sekarang mengelola file kuncinya sendiri?

@nottrobin Saya menduga package-lock.json hanya dihasilkan jika:

package-lock.json secara otomatis dihasilkan untuk setiap operasi di mana npm memodifikasi baik node_modules pohon, atau package.json .

Bagi siapa saja yang tertarik, saya membuat alat kecil yang dapat mengubah package-lock.json menjadi yarn.lock dan sebaliknya. Ingin tahu apakah itu berhasil untuk Anda: https://github.com/imsnif/synp

@nottrobin Skenario saya adalah menghasilkan file package-lock.json untuk proyek di mana sudah ada file yarn.lock untuk jangka waktu yang lebih lama (dan ada versi dependensi yang lebih baru). Oleh karena itu saya telah menggunakan npm-shrinkwrap untuk menghasilkan file kunci untuk pohon node_modules (diinstal oleh benang). npm install akan menghasilkan file kunci dengan versi paket yang mungkin lebih baru. Dan triknya adalah npm-shrinkwrap.json memiliki struktur yang sama dengan package-lock.json (kecuali beberapa metadata yang ditambahkan npm install di akhir).

Sekarang adalah 2018. Masalah ini sangat penting dalam mengatur versi yang konsisten. Tim inti perlu penyelidikan dalam topik ini. Lebih banyak masalah yang digandakan akan ditambahkan dan lebih banyak masalah yang dibuat daripada diselesaikan.
Kemungkinan solusi dari tim inti Benang untuk dipilih:

• Akan menyinkronkan dua file dalam setiap tindakan untuk memberikan kebebasan memilih paket (cara yang baik)
• Menghentikan file kunci sendiri demi default package-lock.json (terbaik menurut saya)
• Hanya akan dibuat sesuai permintaan
• NPM akan menambahkan kemungkinan untuk menambahkan perubahan khusus di package-lock.json dan tidak akan dihapus (gabungkan - terbaik untuk semua orang)

NPM tidak akan menghapus file kunci mereka. Benang dapat (mohon jangan) melakukan sam dan status akan dipertahankan apa adanya (dua file kunci) - Masalah ini kemudian disetel ke "tidak akan diperbaiki" dan menambahkan dokumentasi tentang keputusan.
Perlu keputusan tim inti pendekatan apa yang kita ambil.

NPM tidak akan menghapus file kunci mereka.

$ cat .npmrc
package-lock=false

Sejauh ini ini adalah solusi terbaik yang bekerja untuk saya. Saya mencoba menggunakan file kunci paket, tetapi kecuali https://github.com/npm/npm/issues/17722 diselesaikan, saya tidak melihat bagaimana file kunci npm dapat dianggap bahkan hampir tidak dapat digunakan di tim besar mana pun. Jadi masuk akal bagi benang untuk mempertimbangkan file package-lock.json dan memperbaruinya ketika perubahan pada file kunci asli dibuat, tetapi saya tidak melihat Deprecate own lock file in favor of default package-lock.json (best in my opinion) menjadi solusi yang mungkin dalam waktu dekat

Di CI kami, kami cukup menggunakan:

if [ -e 'yarn.lock' ]; then
    yarn install
elif [ -e 'package-lock.json' ]; then
    npm install
fi

Ini harus menjadi salah satu masalah paling populer yang (tampaknya) benar-benar diabaikan oleh pengelola proyek - berlangsung selama satu tahun sekarang. Bagi saya ini adalah cacat yang cukup signifikan pada reputasi Yarn yang cukup bagus.

Bagi mereka yang menggunakan npm dan benang bersama-sama dalam proyek yang sama, bagaimana Anda mempertahankan perbedaan CLI dalam skrip Anda?

Menggunakan beberapa manajer paket dalam proyek yang sama terdengar seperti menggunakan beberapa sistem kontrol versi dalam proyek yang sama, atau beberapa pelari tugas untuk tugas yang sama. Mereka melakukan hal yang berbeda dalam kasus penggunaan yang sama yang pasti akan menyebabkan konflik yang tidak terdokumentasi.

benang dan npm mungkin terlihat sangat mirip dalam hal fitur, tetapi mereka sangat berbeda dalam implementasinya.
Memberi benang kebebasan untuk menambahkan lebih banyak fitur di yarn.lock tanpa melalui npm terdengar jauh lebih sederhana dan bukti masa depan bagi saya. Pindah ke package-lock.json akan menyebabkan masalah sinkronisasi di masa mendatang ketika npm memutuskan untuk mengubah sesuatu untuk set fitur mereka sendiri.

Ya, npm adalah default sekarang di NodeJS, tapi itu adalah trade-off yang diketahui ketika memilih manajer paket alternatif. Saya pikir kompetisi adalah hal yang baik; sebagaimana dibuktikan dengan banyak fitur npm yang terinspirasi benang setelah periode stagnasi yang lama.

Paling-paling, jika ini belum dilakukan, saya pikir benang harus mendeteksi file kunci lain dalam sebuah proyek, memperingatkan tentang mereka ketika mencoba menjalankan perintah dan memberikan saran yang berguna.

Hai @jahed - kami sebenarnya sedang dalam proses menerapkan hal yang sama. Peringatan ketika lockfile lain ditemukan dan memberikan kemampuan untuk mengimpor darinya. Inilah PR saya yang melakukan yang terakhir sebagai langkah pertama:
https://github.com/yarnpkg/yarn/pull/5745

Semoga kita bisa segera menggabungkannya. Anda dapat mengikuti lebih banyak di sini jika Anda suka:
https://github.com/yarnpkg/yarn/issues/5654

Menggabungkan ke #5654.