Yarn: Lockfiles yang bersaing membuat UX yang buruk

Tambahkan config ke package.json untuk menunjukkan

Ini bisa menjadi kasus penggunaan yang baik untuk bidang engine 🤔

Membulatkan package-lock.json → yarn.lock → package-lock.json adalah kerugian, tapi itu sepertinya tidak penting. yarn.lock → package-lock.json → yarn.lock tidak boleh lossy, AFAIK.

Dari sudut pandang npm , saya menyukai opsi di mana jika yarn melihat package-lock.json dan bukan yarn.lock yang mengimpornya dan menghapus package-lock.json . Dan sama halnya, jika npm melihat yarn.lock dan tidak ada package-lock.json itu harus melakukan hal yang sama, mengimpor dan menghapus `yarn.lock.

Ini akan memungkinkan pengguna dari kedua alat untuk beralih tanpa hambatan bolak-balik tanpa meninggalkan proyek pengguna dalam keadaan yang membingungkan (di mana file tampak berasal dari keduanya).

Saya agak khawatir dengan ini, karena itu berarti bahwa baik package-lock.json atau yarn.lock akan dapat menambahkan metadata ke file (Yarn saat ini tidak, tapi mengapa tidak), menghapus beberapa kebebasan untuk format kami dalam prosesnya.

Masalah ini juga menimbulkan pertanyaan tentang interoperabilitas antara Yarn dan npm secara umum, awalnya dibahas di utas lain - Saya merasa mencoba untuk menjadi terlalu interoperable mungkin pantas untuk kita berdua, karena pengguna kemudian akan memiliki harapan bahwa semuanya akan bekerja dengan cara yang persis sama pada kedua proyek, yang menurut saya merupakan asumsi yang berbahaya (satu contoh nyata adalah bahwa ruang kerja akan diam-diam rusak jika seseorang menjalankan npm pada proyek yang didukung ruang kerja).

@ yarnpkg / core, pikiran?

Saya suka ide @ iarna untuk membuat kedua alat bermigrasi dari satu file kunci ke
yang lain dipasang secara otomatis.
Masuk akal untuk menghapus lockfile yang diimpor setelah migrasi untuk menghindari
Kedua manajer paket bersaing dalam satu proyek.

Kedua alat tersebut dapat mencetak peringatan dan mungkin memerlukan perintah pengguna untuk melanjutkan.

Saya juga setuju dengan pendapat Mael bahwa mencapai kompatibilitas 100% akan terkunci
kami menjelajahi fitur-fitur baru, saya pikir kami harus memperlakukannya sebagai satu kali saja
jalur migrasi, itu bisa menjadi fitur yang agak kecil di install.js di
sisi.

Pada Rabu, 11 Apr 2018 pukul 21:49 Maël Nison [email protected] menulis:

Saya agak khawatir dengan ini, karena itu tidak berarti sama sekali
package-lock.json atau yarn.lock akan dapat menambahkan metadata ke file
(Yarn saat ini tidak melakukannya, tetapi mengapa tidak), menghapus beberapa kebebasan pada format kami
dalam proses.

Masalah ini juga menimbulkan pertanyaan tentang interoperabilitas antara Yarn dan
npm secara umum, awalnya dibahas di utas lain - Saya merasa ingin mencoba
untuk menjadi terlalu interoperabel mungkin pantas untuk kami berdua, karena pengguna akan melakukannya
memiliki harapan bahwa semuanya akan bekerja dengan cara yang persis sama pada keduanya
proyek, yang menurut saya merupakan asumsi berbahaya (salah satu contoh nyata adalah
bahwa ruang kerja akan diam-diam rusak jika seseorang menjalankan npm di
proyek bertenaga ruang kerja).

@ yarnpkg / core https://github.com/orgs/yarnpkg/teams/core , ada pendapat?

-
Anda menerima ini karena Anda berada di tim yang disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/5654#issuecomment-380677110 , atau bisukan
utasnya
https://github.com/notifications/unsubscribe-auth/ACBdWI9jnLJeFqH8v2T-AB74sQO1PMIjks5tntzrgaJpZM4TQ5-B
.

Melakukan ping ke @imsnif sejak dia menyatakan minatnya untuk mengimplementasikan solusi "Ubah file kunci lain" beberapa minggu yang lalu. Dia bahkan mungkin memiliki beberapa kode yang berfungsi sekarang.

Terima kasih atas pingnya!

Jadi ya, saya sebenarnya sedang mengerjakan hal ini. Saya berencana menulis benang RFC dan melakukan ping ke semua pemegang saham minggu depan.

Jadi secara singkat: Saya telah melakukan beberapa pekerjaan untuk mengubah yarn.lock <==> package-lock.json. Ada beberapa kerugian dalam prosesnya, tetapi sangat sedikit yang logis. Di mata saya, ini benar-benar dapat diterima jika kita berbicara tentang skenario 'konversi satu kali' yang disebutkan di atas. Jika kita ingin membahas ini lebih lanjut, saya bisa menjelaskan lebih detail.

Saat ini saya memiliki beberapa kode dasar yang melakukan ini: https://github.com/imsnif/synp
Ini bukan 100% dan bergantung pada folder node_modules yang ada dan saat ini untuk proyek yang akan dikonversi. Saya sedang dalam tahap akhir penulisan ulang (di cabang 2.0.0 ) yang akan mendapatkan status paket dari registri (menggunakan pacote lib yang mengagumkan).

Apa yang ingin saya lakukan setelah selesai adalah mulai berbicara tentang bagaimana (dan jika?) Kita ingin menerapkan ini tepat di yarn dan npm .

Akan sangat senang mendengar pendapat semua orang tentang ini.

Di mata saya, ini sepenuhnya dapat diterima jika kita berbicara tentang skenario 'konversi satu kali' yang disebutkan di atas

Saya tidak berpikir itu akan menjadi umum. Saya mungkin salah, tetapi saya merasa kasus penggunaan yang lebih umum adalah proyek yang menggunakan Yarn, dan salah satu pengembang menyalin / menempelkan perintah dari README untuk menambahkan ketergantungan, menggunakan npm daripada yarn dalam prosesnya.

Dalam konteks ini, saya masih tidak yakin adalah hal yang baik untuk kehilangan data dan mengubah tata letak paket secara diam-diam dengan mencoba melakukan hal yang benar - mereka mungkin bahkan tidak akan menyadarinya sampai ada yang rusak (kita dapat meminta konfirmasi, tetapi Saya mengharapkan orang-orang yang menyalin / menempelkan perintah-perintah itu juga secara membabi buta mengonfirmasi petunjuk pemasangan). Lebih buruk lagi, itu bisa bekerja di mesin mereka sendiri, tetapi merusak mesin rekan mereka begitu mereka beralih kembali ke Yarn.

@arcanis - Saya pikir semua skenario dan kasus tepi sangat layak untuk didiskusikan. Dalam skenario yang Anda sebutkan, saya sangat setuju, tetapi saya pikir ada skenario lain di mana harus ada bias yang jelas terhadap satu file kunci.

Saya melihat fitur ini terutama digunakan di lingkungan CI, di mana menurut saya fitur ini dapat bersinar (seperti yang disebutkan OP). Paling tidak, saya pikir kedua alat harus mengetahui lockfile alat lain? Meninggalkan secara spesifik kapan mereka memutuskan untuk membuat konversi kepada mereka. Bagaimana menurut anda?

Saya melihat fitur ini terutama digunakan di lingkungan CI, di mana menurut saya fitur ini dapat bersinar (seperti yang disebutkan OP).

Apakah kamu punya contoh? Sistem CI seharusnya bertindak dengan cara yang sangat deterministik, secara tidak sengaja melakukan penguncian file yang dikonversi adalah sesuatu yang harus ditangkap lebih buruk pada waktu PR, CI sudah terlambat untuk ini.

Paling tidak, saya pikir kedua alat harus mengetahui lockfile alat lain?

Mungkin. Menggunakan versi engine untuk memaksa manajer paket tertentu terlihat lebih bersih bagi saya, kedua proyek hanya perlu menyimpan daftar mesin eksklusif (seperti "benang" tidak dapat dipenuhi pada "npm", dan sebaliknya).

Dalam benak saya, mengubah file kunci dengan cepat juga tidak terlalu skalabel. Sebagai contoh, kita baru saja membicarakan tentang file package-lock.json sampai sekarang, tapi menurut saya pnpm memiliki file kunci sendiri yang disebut shrinkwrap.yaml . Alangkah baiknya kita bisa menemukan cara untuk menangani keduanya dan format lain yang mungkin muncul dengan satu batu.

Saya melihat fitur ini terutama digunakan di lingkungan CI, di mana menurut saya fitur ini dapat bersinar (seperti yang disebutkan OP).

Juga perhatikan bahwa jika saya mengerti dengan benar, npm saat ini sedang mengerjakan manajer paket yang sangat ringan khusus CI, yang mungkin tidak berfungsi dengan baik dengan hal-hal yang membutuhkan logika bisnis yang berat seperti konverter lockfile.

Mengenai CI:
Pikiran awal saya adalah: peringatkan saat menambahkan paket baru dengan alat yang berlawanan, ubah saat melakukan penginstalan baru (atau lebih konservatif: gagal secara default pada penginstalan baru dan secara verbal mengizinkan konversi melalui perintah import atau bendera konfigurasi untuk menginstal).

Ketika saya sebelumnya bekerja di lingkungan campuran npm / benang, pada dasarnya kami akan melakukan ini secara manual dengan sejarah git. Itu adalah proses yang melelahkan dan saya yakin kami / tidak sendirian dalam hal ini.

Adapun skalabilitas:
Saya ingin menjelaskan hal ini juga.
Ketika konversi dilakukan, pohon paket logis dan fisik perantara (jika lockfile memilikinya) dibuat. Saat mengonversi ke file kunci yang diinginkan, pohon-pohon itu digunakan (atau dibuat dengan default yang waras jika kita mengonversi dari yarn dan tidak memiliki pohon fisik).
Dengan cara ini, kita dapat dengan mudah mengkonversi antara jenis lockfile lainnya (yang perlu kita lakukan adalah menyediakan konversi ke / dari pohon logis / fisik untuk setiap jenis).

Ini jelas sedikit di depan kemampuan alat sekarang, tetapi saya tidak melihat penerapan ini sebagai masalah besar.

(untuk alat ci baru npm - saya mengerti maksud Anda, tapi saya pikir ini sedikit lebih cepat dari diskusi saat ini?)

atau lebih konservatif: gagal secara default pada penginstalan baru dan secara lisan mengizinkan konversi melalui perintah import

Ya, saya benar-benar akan menambahkan logika konversi ini ke dalam perintah yarn import , sepertinya fitur berguna yang dapat diekstraksi ke dalam paket terpisah jika / ketika kita menerapkan plugin Yarn :) Komentar saya adalah berfokus pada perilaku default yang harus kita adopsi.

Mulai dari npm@6 , Anda harus dapat mengonversi package-lock.json -> yarn.lock tanpa kerugian, tanpa harus menjalankan penginstalan terlebih dahulu. Ini harus berisi semua data yang Anda butuhkan, pengidentifikasi, dll (npm @ 6 's pkglock memiliki rentang versi di bidang requires , yang cocok dengan apa yang digunakan yarn.lock ?)

Oh, dan Anda juga perlu https://github.com/yarnpkg/yarn/pull/5042 untuk dikirim sebelum ini benar, juga, karena npm tidak memiliki sha1 di pkglock di banyak kasus.

@arcanis - fantastis! Begitu pula dengan PR dengan:

1. Peringatan saat menginstal dan menemukan file package-lock.json
2. Peringatan saat menambahkan dan menemukan file package-lock.json
3. Menambahkan kemampuan untuk mengonversi dari package-lock.json melalui perintah import (dan menghapus file setelahnya)
   Bisa diterima? (agar kami memiliki sesuatu yang dapat kami gunakan untuk memulai percakapan secara spesifik)

@zkat - itu hebat tentang npm@6 ! Jika terserah saya, saya akan memilih untuk menggunakannya dan kembali ke file manifes untuk mendukung semua versi lockfile. Bisakah saya bertanya apakah Anda terbuka untuk menerapkan perilaku serupa (atau mungkin agak berbeda) untuk npm ?

Juga perhatikan bahwa jika saya mengerti dengan benar, npm saat ini sedang mengerjakan manajer paket yang sangat ringan khusus CI, yang mungkin tidak berfungsi dengan baik dengan hal-hal yang membutuhkan logika bisnis yang berat seperti konverter lockfile.

Jika yang Anda maksud dengan "saat ini sedang dikerjakan" adalah "telah dikirim" maka ya. =)

Seperti yang Anda sarankan, saat ini memuat yarn.locks berada di luar cakupannya (karena tidak tahu bagaimana menata letak pohon paket) tetapi jika kita semua berakhir dengan perpustakaan yang dapat melakukan tata letak itu, saya tidak menentang untuk mendukung pemuatan benang. kunci. (Idealnya ini akan menjadi pustaka yang dibagi antara itu dan Benang.) Jelas untuk kasusnya itu tidak boleh menghapus file kunci yang ada. Ini murni hanya-baca sejauh metadata paket berjalan.

Peringatan saat menginstal dan menemukan file package-lock.json

Saya khawatir bahwa hanya memiliki peringatan ketika ada jenis file kunci yang tidak didukung tidak akan membantu dengan masalah yang diangkat oleh @jmorrell yang

Saya khawatir bahwa hanya memiliki peringatan ketika ada jenis file kunci yang tidak didukung tidak akan membantu dengan masalah yang diangkat oleh @jmorrell yang

Peringatan akan menjadi peningkatan, tetapi kesalahan dengan pesan yang bagus akan ideal untuk pengguna imo. Saya hanya dapat berbicara untuk diri saya sendiri, tetapi saya memiliki beberapa proyek, beberapa yang menggunakan benang dan beberapa yang menggunakan npm, dan saya sering menemukan diri saya mengetik yang salah untuk proyek itu. Kesalahan cepat berarti saya dapat segera menggunakan kesalahan yang seharusnya saya miliki dari awal.

Jika itu peringatan, itu harus besar dan jelas. Pengguna IME cukup terlatih untuk mengabaikan output dari manajer paket mereka selama itu berhasil.

Saya telah menghubungi beberapa orang yang memiliki lebih banyak pengalaman dengan pengembang pemula yang mudah-mudahan akan ikut memahami seperti apa pengalaman itu bagi seseorang yang baru saja memulai.

Sistem CI seharusnya bertindak dengan cara yang sangat deterministik, secara tidak sengaja melakukan penguncian file yang dikonversi adalah sesuatu yang harus ditangkap lebih buruk pada waktu PR, CI sudah terlambat untuk ini.

Saya setuju. Idealnya pada saat aplikasi tersebut tiba di layanan build / CI, aplikasi tidak berada dalam status tidak pasti. Satu-satunya cara saya merasa nyaman untuk tidak gagal dalam membangun dalam kasus ini adalah jika ada cara yang diterima bagi pengguna untuk menunjukkan preferensi mereka di package.json , tetapi solusi itu juga memberi lebih banyak beban pada pengguna.

Saya khawatir bahwa hanya memiliki peringatan ketika ada jenis file kunci yang tidak didukung tidak akan membantu dengan masalah yang diangkat oleh @jmorrell yang

Ini akan membantu mereka dengan memperingatkan pengguna bahwa mereka melakukan sesuatu yang mungkin tidak mereka inginkan sebelum mereka benar-benar mendorong Heroku. Saya tidak yakin seberapa besar hal itu akan benar-benar mengubah angkanya, tetapi itu adalah sesuatu yang dapat kita periksa dalam beberapa minggu dan melihat apakah kita perlu melangkah lebih jauh. Dan karena perubahan yang dibutuhkan relatif kecil, itu mungkin iterasi pertama yang baik.

Pertanyaan jujur ​​bagi mereka yang mengajukan peringatan: Apakah ada situasi di mana menjalankan yarn install atau yarn add sementara package-lock.json hadir bukan merupakan kesalahan? Ditto untuk npm install dan yarn.lock

Bermigrasi dari npm ke Yarn, atau dari Yarn ke npm, terlintas dalam pikiran. Saya lebih memilih untuk menghindari menambahkan gesekan ketika seseorang ingin mencoba pengelola paket lain.

Satu hal yang juga perlu diingat adalah bahwa peringatan dan kesalahan tidak saling eksklusif, atau setidaknya tidak dengan bidang engine . Proyek tanpa pengelola paket yang disematkan dapat mencetak peringatan, dan proyek dengan pengelola paket yang disematkan dapat mengalami kesalahan. Dengan cara ini pengguna dapat dengan bebas beralih dari satu manajer paket ke yang lain, sampai mereka membuat pilihan dan mengkonfigurasi package.json mereka dengan sesuai.

Keuntungan lain dari bidang mesin adalah memungkinkan Anda mengetahui dengan pasti versi mana dari pengelola paket yang harus digunakan. Saya kira itu dapat dikonfigurasi di suatu tempat, tetapi dengan sistem ini itu akan menjadi bagian dari alur kerja biasa.

Keuntungan lain dari bidang mesin adalah memungkinkan Anda mengetahui dengan pasti versi mana dari pengelola paket yang harus digunakan. Saya kira itu dapat dikonfigurasi di suatu tempat, tetapi dengan sistem ini itu akan menjadi bagian dari alur kerja biasa.

Apakah ada bidang engine atau apakah Anda mengacu pada engines ? Saya tidak dapat menemukan dokumen apa pun yang merujuk ke engine . Maaf jika saya melewatkan sesuatu.

Kami mendukung versi yang ditentukan dalam bidang engines : https://devcenter.heroku.com/articles/nodejs-support#specifying -an-npm-version

Ex:

  "engines": {
    "npm": "5.6.x"
  }

Ada beberapa kekhawatiran yang saya miliki dengan menggunakan ini untuk menentukan pengelola paket mana yang akan digunakan:

• Tampilannya hari ini: sejumlah pengguna yang tidak sepele memiliki npm dan yarn ditentukan, atau versi npm, tetapi kemudian mereka memiliki yarn.lock . Versi mendatang dari npm dan yarn dapat menerapkan ini, tetapi pengguna yang tidak sering meningkatkan akan terus menggunakan versi saat ini untuk waktu yang lama.

• Sebagian besar pengguna tidak pernah menyentuh konfigurasi ini. Mereka mencabang boilerplate lama yang menentukan Node 0.10 meskipun mereka menggunakan apa pun yang mereka unduh dari nodejs.org di mesin mereka. Hal ini menyebabkan sejumlah masalah yang tidak sepele di Heroku.

• Teams sering kali tidak mengoordinasikan versi mana yang telah mereka instal. Versi Node atau npm atau benang yang telah mereka pasang sering kali adalah versi apa pun yang terkini ketika mereka memulai suatu proyek atau terakhir kali salah satu dari mereka rusak dan memaksanya untuk menginstal ulang. Bukan berarti ini ideal, tetapi pemahaman saya adalah bahwa mayoritas pengguna npm / yarn adalah pemula, dan ini menambah rintangan baru untuk memulai.

Contoh: "Saya menggandakan contoh proyek hello-world, mendownload Node dari https://nodejs.org , dan tidak berhasil"

Semua yang dikatakan, saya akan senang, senang, senang jika alat menerapkan versi yang ketat dan mencatatnya dalam engines . Ini akan mencegah banyak kesalahan yang saya lihat setiap hari, tetapi itu terasa seperti perubahan yang jauh lebih besar.

Semua yang dikatakan, saya akan senang, senang, senang jika alat tersebut menerapkan versi yang ketat dan merekamnya di mesin. Ini akan mencegah banyak kesalahan yang saya lihat setiap hari, tetapi itu terasa seperti perubahan yang jauh lebih besar.

Benang AFAIK memberlakukan bidang ini secara ketat kecuali jika Anda memberikan bendera untuk menonaktifkannya.

Teams sering kali tidak mengoordinasikan versi mana yang telah mereka instal. Versi Node atau npm atau benang yang telah mereka pasang sering kali adalah versi apa pun yang terkini ketika mereka memulai suatu proyek atau terakhir kali salah satu dari mereka rusak dan memaksanya untuk menginstal ulang.

Ini cukup berbahaya, terutama saat menggunakan Yarn karena hanya menjamin konsistensi di versi utama Yarn yang sama.

Bukan berarti ini ideal, tetapi pemahaman saya adalah bahwa mayoritas pengguna npm / yarn adalah pemula, dan ini menambah rintangan baru untuk memulai.

Bagaimana dengan Yarn (dan juga npm, jika mereka menyukai ide tersebut) menambahkan entri "yarn": "^<current_version>" ke bidang engines untuk membantu memperkenalkan keamanan tanpa terlalu banyak gesekan? Kita dapat menambahkan ini secara otomatis saat menjalankan yarn init , yarn import atau saat kita membuat file kunci dari awal.

Saya tidak tahu banyak tentang Yarn, tapi menurut saya solusi terbaik adalah menambahkan parser package-lock.json ke dalam Yarn dan tidak membuat yarn.lock jika ada.

Saya pikir tujuan akhirnya harus memiliki satu format file kunci yang dibagikan di antara Yarn dan npm.

@thatlittlegit Anda akan senang mengetahui tentang https://github.com/yarnpkg/yarn/pull/5745 lalu. (npm akan melakukan hal yang sama secara terbalik, jadi kita akan berakhir di tempat di mana tidak masalah file kunci apa yang Anda gunakan atau alat apa yang Anda pilih.)

Diedit untuk menambahkan: Menurut saya, format file kunci tunggal bukanlah hasil yang mungkin karena ada pengorbanan yang berbeda antara format file kunci dan kurangnya konsensus tentang mana yang terbaik. Saya pikir memiliki kedua alat yang dapat saling memahami lockfile satu sama lain sudah cukup.

Di luar itu, ada banyak keuntungan memiliki beberapa alat yang digunakan secara aktif yang membuat pengorbanan berbeda karena itu berarti kasus penggunaan pengguna dapat dipenuhi dengan lebih baik daripada dengan solusi umum tunggal.

@BYK Beberapa riwayat tentang perilaku bidang mesin mungkin akan membantu di sini:

Dalam npm @ 1 dan npm @ 2 , kami memiliki package.json disebut engineStrict sebagai tambahan pada bidang engine . Jika engineStrict benar maka bidang mesin digunakan sebagai _resolution constraint_ dan sebelum kami menerapkan rentang semver ke daftar versi, versi dengan mesin yang tidak kompatibel akan disaring. Ini akan memungkinkan Anda melakukan hal-hal seperti npm install foo dan mendapatkan [email protected] meskipun [email protected] diterbitkan jika [email protected] tidak didukung pada platform Anda. _Tampaknya_ ini diinginkan, tetapi dalam praktiknya sangat membingungkan, terutama karena dokumen di situs web hanya untuk versi terbaru.

Jika engineStrict salah maka resolusi dilakukan tanpa memperhatikan bidang mesin dan peringatan akan dikeluarkan jika hasilnya tidak kompatibel.

Ada JUGA opsi konfigurasi engine-strict , yang melakukan hal yang sama seperti properti package.json , tetapi menerapkannya ke SEMUA paket.

Mulai dari npm @ 3 , kami menghentikan dukungan untuk properti engineStrict package.json dan mengubah perilaku opsi engine-strict config. Opsi config sekarang mengubah peringatan yang Anda peroleh menjadi kesalahan, tetapi tidak memengaruhi resolusi.

Field engine diberlakukan tidak hanya untuk proyek tingkat atas tetapi juga secara transitif. Memperkenalkan flag mesin yarn akan menyiratkan bahwa dependensi hanya dapat diinstal dengan benang dan saya rasa itu tidak terjadi di sini.

Karena dalam rilis yarn kita harus memiliki kemampuan untuk mengimpor package-lock.json menjadi yarn.lock - Saya ingin kembali membahas masalah peringatan / kesalahan.

Cara saya melihatnya: Saya tidak berpikir ada alasan yang baik untuk satu paket memiliki file package-lock.json dan yarn.lock . Sebagian besar proyek yang pernah saya lihat yang secara sadar melihatnya sebagai masalah yang perlu diperbaiki daripada situasi yang diinginkan (tetapi saya tentu saja terbuka untuk diperbaiki).
Seperti yang saya pahami dari penjelasan @iarna di atas, kolom engine tidak akan menjadi solusi yang baik untuk secara eksplisit menentukan manajer paket mana yang digunakan paket.
Jadi IMO, ini adalah situasi yang seharusnya menghasilkan kesalahan verbose yang akan mengundang pengguna untuk menghapus satu file atau mengubahnya.

Namun, saya pikir menghasilkan kesalahan seperti itu akan menjadi perubahan yang jelas. Di sisi benang, saya akan mengusulkan memulai dengan peringatan (seperti yang disebutkan di atas) dan perlahan-lahan menghentikan perilaku ini sampai versi utama berikutnya di mana itu akan diubah menjadi kesalahan (mungkin menambahkan bendera konfigurasi yang akan memungkinkan kedua file untuk ada secara bersamaan).

Apa yang dipikirkan semua orang? @jmorrell , @BYK , @arcanis , @iarna?

Tampaknya aneh bagi saya bahwa setiap jenis proyek harus menentukan alat manajemen paket apa yang harus digunakan. Koreksi saya jika saya salah, tetapi saya melihat Yarn sebagai pengganti drop-in yang sebagian besar bergantung pada preferensi pengguna akhir. Apakah Yarn mencoba untuk menggantikan NPM sepenuhnya sebagai standar de facto, atau apakah Yarn berusaha untuk hidup berdampingan?

@BrainBacon Anda hanya mendapatkan keuntungan dari dependensi terkunci jika semua orang menggunakan manajer paket yang sama yang menghormati file kunci yang sama dan menggunakan semantik yang sama. Jika sebuah proyek memiliki yarn.lock dan seseorang kemudian menjalankan npm install , orang tersebut masih bisa mendapatkan set dependensi yang berbeda. Jadi tidak, ini tidak bergantung pada preferensi pengguna akhir, sayangnya - sebaiknya, semua orang di proyek menggunakan pengelola paket yang sama.

Ini juga berarti tidak masuk akal untuk memiliki dua file kunci dalam sebuah proyek. Mereka tidak mungkin menyelesaikan pohon ketergantungan yang sama, dan membuatnya tidak jelas bagi kontributor manajer paket mana yang akan digunakan.

(Bagian pengganti drop-in benar terutama ketika npm tidak menghasilkan file kunci, karena tidak ada informasi yang hilang di sana. Ini juga masih benar jika # 5745 benar-benar berarti bahwa Yarn sekarang dapat menghasilkan file kunci berdasarkan package-lock.json , tetapi itu hanya berarti bahwa _project_ kemudian dapat dengan mudah mengganti npm dengan Yarn. Namun, karena Anda masih perlu memeriksa lockfile baru, semua kontributor perlu beralih.)

Koreksi saya jika saya salah, tetapi saya melihat Yarn sebagai pengganti drop-in yang sebagian besar bergantung pada preferensi pengguna akhir.

Yarn bukanlah pengganti langsung dalam hal API yang terbuka. yarn add <pkg> vs npm install <pkg> adalah contoh nyata dari sesuatu yang kami lakukan secara berbeda. Kami cenderung memiliki kumpulan fitur yang sama, tetapi pada akhirnya itu adalah dua alat yang berbeda dan terkadang kami memiliki solusi berbeda untuk masalah yang sama.

yarn.lock vs package-lock.json adalah salah satu perbedaan itu dan saya yakin baik Yarn maupun npm tidak tertarik untuk menggunakan satu pun, karena keduanya berisi informasi yang berbeda.

Di sisi benang, saya akan mengusulkan memulai dengan peringatan (seperti yang disebutkan di atas)

Saya akan baik-baik saja dengan ini. Sesuatu seperti:

WARN Your project seem to contain lock files (package-lock.json, shrinkwrap.json) generated
WARN by other tools than Yarn. It is advised not to mix package managers, in order to avoid
WARN resolution inconsistencies caused by desynchronized lock files.

Apakah seseorang ingin membuka PR?

Saya akan dengan senang hati membuka PR yang menambahkan peringatan :)

Apakah solusi akhir yang diinginkan di sini merupakan kesalahan yang berguna ketika package-lock.json ada + yarn import ? Pemahaman saya adalah bahwa @iarna menganjurkan bahwa setiap alat harus menghapus / mengonversi file kunci yang berlawanan jika ada secara otomatis.

Solusi mana pun akan menjadi peningkatan yang signifikan bagi pengguna, tetapi saya pikir akan lebih baik jika benang dan npm memilih strategi yang sama (meskipun tidak sepenuhnya diperlukan jika tidak ada kesepakatan dan orang-orang sangat menyukainya).

@jmorrell - pemahaman saya adalah bahwa kami menyetujui konversi otomatis adalah ide yang buruk di sini.

Sebagian besar karena sulit untuk mengetahui apa seharusnya delta antara dua file kunci.
Misalnya. ketika saya melihat peringatan di atas sebagai pengembang, apa yang mungkin ingin saya lakukan adalah mencari tahu kapan lockfile lain dibuat, paket apa yang ditambahkan ke dalamnya yang tidak ditambahkan ke lockfile utama saya dan kemudian menambahkannya. Mungkin menggunakan opsi import sebagai referensi, tetapi belum tentu.

Saya harap orang-orang npm setuju dengan yang ini?

Idealnya, saya ingin peringatan untuk memasukkan sesuatu tentang situasi ini menjadi usang (tidak yakin tentang kata-katanya) dan bahwa versi benang masa depan akan menghasilkan kesalahan. Mungkin menautkan ke beberapa dokumentasi terperinci tentang ini dan cara mengatasinya. @arcanis - apakah menurut Anda itu layak, atau apakah Anda lebih suka tetap menggunakan perilaku warning ?

Jika kedua alat mengeluarkan error ketika ada beberapa file kunci, saya merasa pengembang akan memahami masalah ini saat masih "kecil" dan dapat mengatasinya dengan cepat (dengan bantuan mengimpor sebagai referensi atau tanpa) .

@arcanis npm add <pkg> benar-benar valid dan melakukan apa yang dilakukan Yarn 👼

Sejauh pkglock vs yarnlock, maksud asli dari package-lock.json adalah untuk membuat format yang menyertakan semua data yang dibutuhkan oleh pengelola paket. Faktanya, pkglock mulai dari npm@6 dapat secara transparan diubah menjadi yarn.lock tanpa menjalankan penginstal, karena ini menjelaskan pohon lengkap dengan semua metadata yang relevan. Kami melakukan itu _ secara tidak sengaja_ (seperti bidang requires ), dan kami meminta umpan balik dari tim Yarn dan pnpm untuk memastikan bahwa apa pun yang kami lakukan cukup bagi keduanya untuk digunakan baik sebagai file kunci yang dapat diimpor atau sebagai pilihan alternatif. yarn.lock, sayangnya, merupakan subset lossy sehingga kebalikannya tidak benar, tetapi kami akan tetap menambahkan barang untuk mengimpornya. npm bahkan akan mematuhi bentuk pohon yang dihitung dengan Benang (tidak seperti Benang, yang tidak akan).

Nyatanya, pkglock mulai dari npm @ 6 dapat secara transparan diubah menjadi sebuah yarn.lock tanpa menjalankan penginstal, karena ini menjelaskan pohon lengkap dengan semua metadata yang relevan.

Saya tidak berpikir itu bisa (tapi mungkin saya salah, jangan ragu untuk menunjukkan kesalahpahaman). File kunci Benang tidak mendukung dengan desain beberapa rentang menyelesaikan ke satu versi. Jika Anda memiliki beberapa paket masing-masing tergantung pada lodash@^1.0.0 , semuanya akan menggunakan versi yang sama persis. Ini bukan hanya pengoptimalan, tetapi juga cara kami menyandikan berbagai hal di file kunci kami.

Npm lockfile menjadi sebuah pohon, properti ini tidak dijamin, dan beberapa rentang identik mungkin menggunakan versi yang berbeda (yang tidak masalah, karena ini mungkin memungkinkan pengoptimalan yang sedikit lebih baik dengan mengeksploitasi aturan resolusi Node). Dalam keadaan seperti itu, konversi package-lock.json -> yarn.lock akan menjadi lossy, karena kita tidak memiliki pilihan lain selain menggabungkannya menjadi satu.

Di sisi lain, file kunci Yarn dapat diubah menjadi package-lock.json relatif tanpa masalah, karena aturan kami adalah bagian yang lebih ketat dari Anda (rentang gabungan kami dapat diubah menjadi pohon tanpa kehilangan, pohon tidak dapat diubah menjadi rentang gabungan tanpa kerugian). Perhatikan bahwa saya hanya berbicara tentang pohon ketergantungan itu sendiri, saya tidak terbiasa dengan bidang metadata Anda.

Sejujurnya saya tidak sepenuhnya yakin apakah kita mengatakan hal yang sama atau sesuatu yang sama sekali berbeda, saya hanya ingin menjelaskan sedikit situasinya 🙂

Idealnya, saya ingin peringatan untuk memasukkan sesuatu tentang situasi ini menjadi usang (tidak yakin tentang kata-katanya) dan bahwa versi benang masa depan akan menghasilkan kesalahan. Mungkin menautkan ke beberapa dokumentasi terperinci tentang ini dan cara mengatasinya.

@imsnif Saya tidak yakin tentang ini menjadi kesalahan di lingkungan non-CI (tidak ada pertanyaan tentang CI - ini adalah sesuatu yang pasti akan memicu kesalahan). Saya lebih suka tetap menggunakan peringatan yang hanya menjelaskan keadaan saat ini, dan menjelaskan mengapa itu tidak ideal.

Hal yang baik adalah @jmorrell akan dapat memberi kami metrik yang tepat untuk melihat apakah peringatannya sudah cukup, dan berdasarkan itu kami akan memilih langkah selanjutnya.

Apakah solusi akhir yang diinginkan di sini merupakan kesalahan yang membantu ketika package-lock.json ada + impor benang?

Ya, ditambah dengan mode "upgrade-to-error-on-CI" * Saya rasa ini adalah langkah pertama yang masuk akal!

(* Ini belum ada, saya akan menyebutkannya di # 5773 Yarn 2.0 WG)

@arcanis - Tentang @zkat (tapi tolong @zkat perbaiki saya jika saya salah atau salah paham) adalah bahwa package-lock.json menyimpan pohon fisik dan logis, sementara yarn.lock hanya menyimpan pohon logis. Jadi seperti yang disebutkan sebelumnya, mengubah package-lock.json => yarn.lock => package-lock.json akan kehilangan data pohon fisik. IMO dalam banyak kasus tidak masalah, tetapi ada pengecualian: mis. dependensi yang dibundel.

Pendapat pribadi saya adalah bahwa kedua manajer paket bisa mendapatkan keuntungan dari sinkronisasi konstruksi pohon fisik mereka. Dari apa yang saya lihat, kami mungkin dapat mengekstrak beberapa aturan yang didefinisikan dengan baik tentang bagaimana pohon fisik dibuat dan keduanya mengikutinya (idealnya dengan modul yang dikelola oleh semua pemangku kepentingan). Saya pikir ini akan menyelesaikan masalah kompatibilitas, beberapa masalah yang dimiliki yarn dengan dependensi yang dibundel, sementara masih memungkinkan setiap manajer paket untuk mempertahankan kebiasaan uniknya. (Meskipun diakui, saya cukup baru dalam diskusi ini, jadi mungkin ada hal-hal yang tidak saya sadari - permintaan maaf saya jika saya membangunkan beberapa anjing yang sedang tidur).

Untuk masalah yang sedang dihadapi: @arcanis - Saya akan mencoba menawarkan satu argumen lagi di sini untuk mendukung kesalahan selimut dalam situasi ini, dan jika Anda tidak setuju kami dapat tetap dengan peringatan sejauh yang saya ketahui:
Meskipun memang cukup penting untuk menangkapnya pada tingkat CI, saya pikir kesalahan di sana akan jauh lebih sulit untuk di-debug (rata-rata) daripada kesalahan di lingkungan lokal pengembang.
Jika pengembang mendapatkan kesalahan di lingkungan lokalnya karena menggunakan alat yang salah, mereka (kemungkinan) tidak akan melangkah lebih jauh. Mereka hanya akan mengatakan "ups", dan menggunakan alat lainnya. Ini akan menghemat banyak waktu, sebagai ganti menangkapnya di CI setelah mengembangkan fitur dan kemudian mundur.
Peringatan (seperti yang disebutkan sebelumnya di sini) mungkin tertelan di beberapa orang lain yang cenderung diabaikan oleh pengembang jika status keluarnya adalah 0.
Bagaimana menurut anda?

Juga - dalam situasi yang saya jelaskan di atas, lockfile "asing" dapat ditempatkan di .gitignore dan CI bahkan tidak akan mendapat kesempatan untuk mengetahuinya. Sebagai pengembang yang linglung, saya mungkin berpikir "Yah, ini memberi saya peringatan yang tidak jelas tentang lingkungan lokal saya, tetapi lolos CI - jadi mungkin hanya masalah lokal di pihak saya - ah baiklah"

Peringatan (seperti yang disebutkan sebelumnya di sini) mungkin tertelan di beberapa orang lain yang cenderung diabaikan oleh pengembang jika status keluarnya adalah 0.

Maksud saya adalah penegasan ini tidak didukung oleh data apa pun, meskipun kami memiliki cara untuk mengumpulkan beberapa untuk kemudian membuat keputusan yang tepat. Dalam konteks ini, memilih opsi yang lebih radikal yang akan merusak alur kerja orang menurut saya agak sia-sia dan berpotensi berbahaya harmful

Selain itu, saya pikir Anda agak mengabaikan cerita pengguna "Saya menggunakan manajer paket dan ingin mencoba yang lain", yang menurut saya cukup penting bagi semua orang yang terlibat, baik pengelola pengelola paket maupun pengguna. Tidaklah bagus jika orang tidak dapat dengan mudah mencoba npm 6 dari proyek Yarn mereka (atau sebaliknya, untuk mencoba Yarn dari proyek npm mereka).

Pendapat pribadi saya adalah bahwa kedua manajer paket bisa mendapatkan keuntungan dari sinkronisasi konstruksi pohon fisik mereka.

Ini adalah topik yang berbeda, tetapi saya tidak setuju. Saya pikir ada kesalahpahaman bahwa Yarn adalah npm, yang salah. Jika Anda ingin mengimpor proyek ke proyek lain melalui perintah khusus, saya mendukungnya, tetapi mengonversi (atau membaca) file kunci secara diam-diam dari format pihak ketiga adalah resep untuk bencana:

• itu akan mengabaikan file konfigurasi
• itu akan merusak pohon fisik saat berikutnya sebuah paket ditambahkan / dihapus
• fitur apa pun yang unik untuk manajer paket tidak akan berfungsi (ruang kerja, penggantian resolusi, tautan :, ...)

Maksud saya adalah penegasan ini tidak didukung oleh data apa pun, meskipun kami memiliki cara untuk mengumpulkan beberapa untuk kemudian membuat keputusan yang tepat. Dalam konteks ini, memilih opsi yang lebih radikal yang akan merusak alur kerja orang menurut saya agak sia-sia dan kebingungan yang berpotensi membahayakan

Benar - ini tidak didukung oleh data apa pun. Saya pasti berspekulasi di sini (maaf jika saya tidak menekankan ini). Meskipun kami mungkin dapat memahami tren perbaikan peringatan, kami tidak dapat memahami seberapa nyaman hal ini bagi pengguna dan apakah ada solusi yang lebih nyaman. Jika kita mengandalkan data, saya rasa tidak ada hasil selain "sama sekali tidak ada perubahan dalam tingkat kesalahan penerapan Heroku" yang akan mengarahkan kita menuju solusi kesalahan menyeluruh.

Saya setuju bahwa sangat penting untuk tidak merusak alur kerja orang. Itulah sebabnya saya mengusulkan kesalahan sebagai perubahan yang melanggar 2.0.0 , dengan kata-kata dalam peringatan yang akan mengingatkan pengguna bahwa situasi ini tidak berlaku lagi. Saya juga berpikir kita dapat mengizinkan penggunaan parameter --force atau config untuk menimpa perilaku ini. (Saya yakin ini juga mengatasi Anda mencoba masalah pengelola paket lainnya?)

Ini adalah topik yang berbeda, tetapi saya tidak setuju. Saya pikir ada kesalahpahaman bahwa Yarn adalah npm, yang salah. Jika Anda ingin mengimpor proyek ke proyek lain melalui perintah khusus, saya mendukungnya, tetapi secara diam-diam mengubah (atau membaca) file kunci dari format pihak ketiga adalah resep untuk bencana

Saya pikir Anda menyampaikan kekhawatiran penting di sini yang ingin saya sampaikan. Tapi seperti yang Anda katakan, ini adalah topik yang berbeda dan saya tidak ingin menggagalkan percakapan. Mungkin kita bisa membahasnya dalam masalah terpisah?

Saya pikir percakapan di sini sedikit tergelincir jadi saya ingin merapikannya dengan beberapa klarifikasi dan ringkasan:

1. Benang dan npm memiliki resolusi dan strategi pembuatan pohon fisik yang berbeda dan ini merupakan faktor kunci untuk keberadaan kedua proyek.
2. Kedua file yarn.lock dan package-lock.json dibuat dengan tujuan tertentu dan sejauh yang saya bisa lihat, tujuan ini tidak sepenuhnya selaras tetapi memiliki beberapa tumpang tindih.
3. Perbedaan tujuan ini tidak membuat format lebih unggul dari yang lain pada umumnya, mereka hanya menukar hal yang berbeda.

Berdasarkan ini, menurut saya mempertahankan kedua format itu sebenarnya penting untuk inovasi dan melayani kebutuhan yang berbeda. Apa yang dibutuhkan adalah memastikan portabilitas proyek dengan kehilangan data minimal antara manajer paket tanpa memaksakan strategi manajer paket tertentu ke yang lain untuk memungkinkan percobaan gratis.

Saya melihat pengakuan dan peringatan terhadap file kunci lainnya bersama dengan konversi yang tepat dengan pesan yang jelas tentang apa yang disimpan dan apa yang hilang sebagai nilai yang besar bagi pengguna di setiap sisi. Jadi sekarang pertanyaan di sini dalam masalah ini adalah apa aliran terbaik untuk pengguna yang memiliki file kunci paket di repo mereka saat mereka menjalankan benang .

Sepertinya konversi otomatis berpotensi berbahaya dan pemasangan yang gagal tanpa jalan keluar dapat merugikan orang-orang tertentu. Bagaimana dengan mensyaratkan konfigurasi yang akan ditetapkan untuk benang untuk mengetahui bahwa memiliki file kunci paket dimaksudkan dalam mode CI? Ini adalah sinyal dari pengembang untuk benang, mengatakan "Saya tahu apa yang saya lakukan jadi tolong jangan mencoba melindungi saya dari ketidaksesuaian".

Pikiran?

Bagaimana dengan mensyaratkan konfigurasi yang akan ditetapkan untuk benang untuk mengetahui bahwa memiliki file kunci paket dimaksudkan dalam mode CI? Ini adalah sinyal dari pengembang untuk benang, mengatakan "Saya tahu apa yang saya lakukan jadi tolong jangan mencoba melindungi saya dari ketidaksesuaian".

@BYK - terdengar bagus. Dengan satu tambahan: karena @arcanis meyakinkan saya di sini dan saat terjadi perselisihan, mungkin ada baiknya juga menambahkan peringatan dalam mode non-ci ketika bendera config tidak disetel. Sehingga developer memiliki kesempatan untuk mengetahui bahwa build CI mereka mungkin gagal sebelum mereka melakukan push (dan juga untuk melindungi dari package-lock.json berada di .gitignore ).

@arcanis sebagai @imsnif disebutkan: pkglock menyertakan _both_ tata letak fisik dan logis pohon. Dengan mengikuti versi logis dari pohon (yang menyertakan rentang yang kita hapus dari), Anda dapat membuat dalam memori benang.lock tanpa instalasi atau menjalankan logika penginstal sama sekali. Hanya pencarian pohon :)

Dari catatan rilis NPM 5:

Fitur lockfile standar baru yang dimaksudkan untuk kompatibilitas lintas-paket-manajer (package-lock.json)

Tampaknya tim NPM mengiklankan package-lock.json sebagai solusi universal; apakah mungkin (secara teknis) bergabung dengan kekuatan itu?

Satu solusi yang ingin saya usulkan adalah "gunakan hanya package-lock.json jika sudah ada". Itu pada dasarnya bagaimana NPM "bermigrasi" dari Shrinkwrap ke file json kunci.

Tampaknya tim NPM mengiklankan package-lock.json sebagai solusi universal; apakah mungkin (secara teknis) bergabung dengan kekuatan itu?

Kami sudah membahasnya, silakan periksa utas lainnya jika Anda belum. Ini tidak akan terjadi dalam jangka pendek.

Saya pikir Anda agak mengabaikan kisah pengguna "Saya menggunakan pengelola paket dan ingin mencoba yang lain", yang menurut saya cukup penting bagi semua orang yang terlibat

Ini mungkin bukan hal yang sering terjadi, peralihan konteks. Saya memilih Benang beberapa waktu yang lalu dan belum melihat ke belakang. Saya pikir lebih baik untuk mempertimbangkan keseriusan mengapa file kunci ada di sana. Jadikan ini sebagai kesalahan yang dapat disisihkan, alih-alih peringatan yang akan diabaikan. Ketika seseorang melakukan file kunci, itu karena suatu alasan.

Statistik kami menunjukkan bahwa mayoritas pengguna Yarn juga menggunakan npm. _Projects_ campuran tidak umum, tetapi satu orang yang mengerjakan banyak proyek, beberapa di antaranya adalah npm dan beberapa di antaranya adalah Yarn, cukup umum. Lebih memperumit masalah, menginstal skrip yang menjalankan npm secara langsung adalah suatu hal.

Saya ingin menggunakan benang, tetapi sebagian besar proyek yang saya kerjakan hanya memiliki file package-lock.json . Saya tidak dapat menambahkan file yarn.lock . yarn import lambat dan / atau rusak. Saat ini milik saya
Opsi _only_ adalah membuang benang dan beralih ke npm.

Saya memahami bahwa benang dibuat oleh pengembang khusus benang untuk proyek khusus benang. Tapi bagaimana dengan kita semua?

Hai @Spongman - yarn import tidak boleh rusak. Sekarang seharusnya sudah dapat mengimpor package-lock.json untuk Anda. Jika Anda mengalami masalah, beri tahu kami!

Saya melakukan # 6103

Hai @Spongman - Saya mengomentari masalah ini, kasus khusus ini disebabkan oleh kerusakan package-lock.json . Saya akan senang mengetahui tentang masalah lainnya.

npm dapat menggunakan file package-lock.json baik. benang harus lebih tahan banting.

Menjawab ini di masalah lain - Saya meminta agar diskusi dipindahkan ke sana agar masalah ini tetap pada topik. Terima kasih!

Saya mengamati dan berpartisipasi dengan cermat di https://github.com/yarnpkg/yarn/issues/3614 (dengan saat ini 254: +1: s). Masalah itu sekarang telah ditutup dan diskusi dipindahkan ke sini.

Mengabaikan tantangan praktis, menurut saya sejauh ini UX terbaik akan diberikan oleh opsi yang tidak disebutkan dalam ringkasan di atas, tetapi disebutkan oleh @thatlittlegit :

Saya pikir tujuan akhirnya harus memiliki satu format file kunci yang dibagikan di antara Yarn dan npm.

Yang juga didukung oleh poin @BrainBacon :

Tampaknya aneh bagi saya bahwa setiap jenis proyek harus menentukan alat manajemen paket apa yang harus digunakan.

Sekali lagi, mengabaikan tantangan praktis selama satu menit, argumen kontra teoritis untuk ini dibuat oleh @iarna di utas ini (dan @jhabidas di utas lainnya ):

Ada banyak keuntungan memiliki beberapa alat yang digunakan secara aktif yang membuat pengorbanan berbeda karena itu berarti kasus penggunaan pengguna dapat lebih baik dipenuhi daripada dengan satu solusi umum.

Secara pribadi, saya tidak berpikir argumen ini harus diterapkan dalam kasus ini, seperti yang saya buat di komentar di utas lain (dengan 95: +1: s, 2: -1: s):

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

Namun, menurut saya file kunci berada di luar ruang tempat Yarn dapat mempertahankan independensi secara wajar. package-lock.json dan composer.lock dimasukkan ke dalam repositori , bersama dengan package.json dan composer.json . Ini bukan file khusus alat, melainkan file khusus proyek yang menentukan versi ketergantungan persis yang dijamin dapat digunakan oleh proyek tersebut.

...

Agar Yarn dapat menjadi alat yang berguna, Yarn harus mengizinkan pengembang untuk mengikuti model standar dalam proyek mereka, sehingga proyek dapat tetap tidak bergantung pada alat. Yang, bagaimanapun, adalah mengapa Yarn dibangun di atas package.json dan bukan file dependensi terpisahnya sendiri.

Setelah membaca sebagian besar utas ini, saya masih setuju dengan penilaian awal saya - jika Yarn terus mengonsumsi file ketergantungan package.json dari repositori, idealnya ia harus mengeluarkan file package-lock.json ke dalam repositori , sehingga repositori bisa tetap tanpa alat. Jika Yarn membaca dependensinya dari yarn.json daripada package.json saya tidak akan terus menjelaskan hal ini.

Saya percaya bahwa kami harus mengakui bahwa ini adalah situasi yang ideal , pengalaman pengguna yang mulus. Namun, saya mengerti poin lain @iarna :

Format lockfile tunggal, menurut saya, bukanlah hasil yang mungkin karena ada tradeoff yang berbeda antara format lockfile dan kurangnya konsensus tentang mana yang terbaik

(meskipun saya tidak setuju bahwa "memiliki kedua alat yang dapat saling memahami lockfile satu sama lain sudah cukup").

Jika skenario ideal yang memungkinkan repositori menjadi alat-agnostik jelas tidak dapat dicapai (dan saya melihat banyak komentar tentang bagaimana lockfile yang berbeda dibangun dengan cara yang berbeda secara fundamental dan berisi informasi yang berbeda), maka kemana kita tampaknya akan pergi sepertinya hampir enak, yaitu:

• NPM / Yarn akan mengeluarkan peringatan jika mereka melihat lockfile orang lain (dan mungkin opsi konfigurasi untuk membuatnya menjadi kesalahan)
• Kedua alat menyediakan mekanisme untuk mengubah satu file kunci menjadi file kunci lainnya

Saya tidak berpikir keduanya harus, dalam keadaan apa pun, mengonversi dan menghapus file kunci pihak lain. Ini berarti bahwa pengembang baru akan selamanya mengkonversi dari satu ke yang lain dan kembali, tergantung pada alat apa yang kebetulan digunakan oleh pengembang (mengingat terlalu banyak orang yang berkomitmen dengan git commit -a ).

Saya juga tidak setuju dengan poin @imsnif :

Saya tidak berpikir ada alasan bagus untuk satu paket memiliki file package-lock.json dan file yarn.lock.

Saya pikir itu lancang untuk mendikte apa yang dijalankan oleh pengembang di komputer mereka, atau di lingkungan produksi mereka. Setidaknya sopan untuk tidak menjadi lebih membatasi dari yang Anda butuhkan. Jika proyek Anda hanya dijalankan oleh tim pengembang Anda, dan mereka semua menjalankan perangkat lunak yang persis sama, bagus. Tetapi Anda mungkin memiliki seorang dev yang merasa jauh lebih mudah menggunakan NPM daripada Yarn karena suatu alasan. Dan terutama jika Anda membuat perangkat lunak sumber terbuka, Anda ingin membuatnya semudah mungkin bagi anggota komunitas untuk bangun dan menjalankannya. Mengingat bahwa NPM dan Yarn hanyalah alat untuk menginstal dependensi yang sama dari package.json , mereka seharusnya berfungsi. Seorang dev harus dapat melihat package.json , memiliki alat untuk menafsirkannya, dan tidak perlu khawatir lebih jauh. Yang dulu menjadi kasus sebelum konflik lockfile ini datang sendiri.

Hai @nottrobin - Saya rasa saya mengerti dari mana Anda berasal. Jika kita mengabaikan tantangan praktis dan perbedaan filosofis, pasti akan lebih baik bagi pengguna berbagai alat jika mereka semua menggunakan lockfile yang sama (ini adalah pendapat pribadi saya, tentu saja).

Tetapi karena kita tidak dapat mengabaikan tantangan praktis tersebut dan sebagian besar tampaknya telah setuju bahwa perbedaan filosofis memiliki tempatnya, saya pikir kompromi yang kita dapatkan (yang Anda uraikan di atas) sudah pasti "cukup baik".

Perhatikan bahwa asumsi tersembunyi dalam kompromi tersebut adalah bahwa pilihan alat dibuat per proyek, bukan per mesin pengembang atau lingkungan produksi.

Perhatikan bahwa asumsi tersembunyi dalam kompromi tersebut adalah bahwa pilihan alat dibuat per proyek, bukan per mesin pengembang atau lingkungan produksi.

Ya, saya pikir inilah yang paling mengkhawatirkan saya - meskipun saya pikir dalam skenario yang saya uraikan di atas, masih mungkin untuk memiliki proyek yang mendukung Yarn dan NPM.

Saya benar-benar berpikir bahwa pada akhirnya jika kedua proyek meninggalkan misi mencoba untuk memungkinkan proyek menjadi alat-agnostik maka mereka benar-benar harus berhenti berbagi file ketergantungan. Benang harus beralih membaca yarn.json daripada package.json . Ada lagi yang berantakan dan membingungkan.

Jika npm lockfiles sudah memiliki superset dari hubungan dependensi yang didukung oleh Yarn lockfiles, mengapa tidak mendukung keduanya di Yarn? Yarn dapat beralih ke package.json dan bidang tambahan apa pun yang mungkin diinginkan oleh Yarn dapat ditambahkan di masa mendatang (mirip dengan cara beberapa editor SVG seperti Inkscape mengelola metadata editor). Kemudian Yarn dapat memiliki format dependensi yang sama seperti npm dan kompatibel kembali dengan yarn.lock, mengubah file kunci npm ke struktur apa pun yang diinginkan Yarn dalam memori secara lossily.

Saya benar-benar berpikir bahwa pada akhirnya jika kedua proyek meninggalkan misi mencoba untuk memungkinkan proyek menjadi alat-agnostik maka mereka benar-benar harus berhenti berbagi file ketergantungan. Benang harus beralih membaca yarn.json daripada package.json . Ada lagi yang berantakan dan membingungkan.

Mungkin, mungkin tidak. Tentu saja, ini akan membutuhkan pergantian alat (benang) yang sangat besar. Perubahan yang tidak terlalu radikal dengan manfaat yang lebih langsung dan terukur telah dilewati.

Saya tidak mengatakan itu ide yang buruk, saya hanya mengatakan saya tidak merasa itu praktis.

Saya tidak mengatakan itu ide yang buruk, saya hanya mengatakan saya tidak merasa itu praktis.

Saya setuju bahwa ini sepertinya pertanyaan besar. Tapi yang saya katakan adalah bahwa ini sepertinya masalah yang sangat penting untuk proyek tersebut.

Hingga saat ini, Yarn telah menjadi alat yang dapat dipilih oleh pengembang untuk digunakan daripada NPM untuk menginstal dependensi Node untuk proyek apa pun dengan package.json . Sekarang, seperti yang Anda tunjukkan, itu membutuhkan proyek untuk secara eksplisit memilih antara Yarn dan NPM. Itu adalah perubahan besar , dan tidak boleh dilakukan secara tidak sengaja. Ini adalah titik penting untuk melakukan panggilan itu.

Menurut saya, ada 3 cara ke depan:

1. Terus menjadi pengganti drop-in untuk NPM dengan menemukan cara untuk menyelaraskan Yarn dengan NPM di semua antarmuka tingkat proyek (standarisasi file kunci)
2. Secara sengaja menyimpang dari NPM dengan menggunakan antarmuka tingkat proyek yang secara eksplisit berbeda (mis. yarn.json dan yarn.lock )
3. Gandakan penyediaan setengah dari antarmuka NPM, dan setengah antarmuka yang berbeda. Ini sebenarnya sama dengan poin 2., tetapi jika dilihat kebanyakan orang menyukai poin 1.

Saya yakin opsi ketiga di sini membingungkan seluruh ruang Node, dan sangat melemahkan kedua alat.

Itu masih bisa kompatibel kembali. Yarn bisa saja memiliki built in npm lockfile converter sehingga ketika melihat package-lock.json, ia akan menyimpannya di sana dan mengubahnya menjadi format yarn.lock di memori. Sejauh yang saya tahu, npm tidak dapat melakukan ini karena file kunci Yarn memiliki informasi yang lebih sedikit daripada npm, jadi menurut saya akan lebih baik jika Yarn melakukan standarisasi dengan npm.

@nottrobin Saya pikir Anda sebagian besar benar dalam analisis Anda, namun:

Sekarang, seperti yang Anda tunjukkan, itu membutuhkan proyek untuk secara eksplisit memilih antara Yarn dan NPM. Itu adalah perubahan besar, dan tidak boleh dilakukan secara tidak sengaja.

Saya pikir ini selalu terjadi, atau setidaknya manfaat utama yang awalnya disebut-sebut diberikan oleh Yarn: reproduktifitas pohon ketergantungan. Anda dapat memeriksa yarn.lock , tetapi itu praktis tidak berguna jika pengembang lain menambahkan / menghapus ketergantungan tanpa menghormati file kunci itu.

@nottrobin - Saya setuju dengan @Vinnl. Seperti yang saya sebutkan di atas, sementara saya tidak ingin berada dalam posisi memberi tahu siapa pun bagaimana mereka harus bekerja, saya pikir menggunakan benang dan npm untuk memasang dependensi dalam proyek yang sama adalah antipattern.

Meskipun kedua alat secara teknis dapat melakukan banyak pekerjaan untuk membuat ini berfungsi, saya tidak merasa ini adalah sesuatu yang harus kami dorong sebagai pengelola. Ada manfaat lain yang tak terhitung jumlahnya untuk memiliki file kunci yang dapat dipertukarkan (seperti yang ditunjukkan oleh berbagai diskusi di utas yang berbeda) tetapi saya tidak berpikir ini adalah salah satunya, secara pribadi.

tapi itu praktis tidak berguna jika developer lain menambahkan / menghapus dependensi tanpa memperhatikan lockfile itu.

Ya, saya kira sampai batas tertentu Benang berada di air berlumpur itu sejak awal - keberadaan yarn.lock sudah berarti sebagian memiliki antarmuka sendiri. Saya pikir itu selalu sedikit berantakan untuk dilakukan, yang melayani tujuan Yarn untuk menginginkan orang beralih dari NPM ke Yarn, tetapi tidak kembali.

Tetapi itu adalah keputusan yang saya rasa lebih nyaman untuk dibuat untuk proyek saya, karena setidaknya saya tahu bahwa NPM masih sepenuhnya didukung - karena NPM tidak menyediakan penguncian di tempat pertama, itu akan terus bekerja sebaik biasanya.

Sekarang itu berubah, karena NPM mengunci dependensi. Jika saya memilih untuk mengikat proyek ke Yarn, saya sekarang akan mempertahankan yarn.lock up-to-date, dan bukan package-lock.json , jadi tidak benar lagi bahwa seseorang dapat menggunakan NPM secara efektif pada proyek.

Kedengarannya seperti Anda mengatakan bahwa benang tidak lagi dimaksudkan untuk menjadi pengganti npm? Bahwa itu seharusnya hanya digunakan oleh proyek khusus benang?

Saya pikir jika itu masalahnya, maka Anda berhutang kepada semua orang untuk memperjelas fakta ini di beranda benang - gunakan ini atau npm, bukan keduanya.

Kedengarannya seperti Anda mengatakan bahwa benang tidak lagi dimaksudkan untuk menjadi pengganti npm?

Tidak pernah. Antarmukanya agak meniru npm untuk memudahkan pengguna memahami cara menggunakannya, tetapi sejak awal beberapa hal bekerja secara berbeda. Alasan utama beberapa orang mengira itu adalah pengganti drop-in adalah karena npm hanya kekurangan fitur untuk dibandingkan.

Sekarang npm mengejar beberapa aspek dan memutuskan untuk mengimplementasikan sesuatu secara berbeda, itu hanya mulai menunjukkan bahwa kita memiliki pendekatan yang berbeda dan membuat keputusan yang berbeda (misalnya fitur mirror offline terbaru yang diimplementasikan npm tidak kompatibel dengan yang sudah ada). Jadi singkatnya: itu tidak pernah "aman", itu terjadi begitu saja secara tidak sengaja.

Saya pikir jika itu masalahnya, maka Anda berhutang kepada semua orang untuk memperjelas fakta ini di beranda benang - gunakan ini atau npm, bukan keduanya.

Faktanya, kami memiliki instruksi migrasi . Komentar Anda membuat saya menyadari bahwa sayangnya berisi paragraf yang

Tidak pernah

err ... kalau begitu, Anda perlu berbicara dengan staf pemasaran Anda. https://yarnpkg.com/lang/en/docs/

Yarn menyela secara langsung dengan banyak fitur npm, termasuk format metadata paketnya, memungkinkan migrasi tanpa rasa sakit.

Kami tidak memiliki orang pemasaran, tapi kami menerima PR yang bagus 🙃

Dalam kasus khusus ini kedengarannya tidak terlalu salah. Kami melakukan interop dengan banyak fitur, hanya saja tidak dengan semuanya, dan migrasi tidak menimbulkan rasa sakit dalam banyak kasus (lebih buruk lagi, jaraknya yarn import ).

migrasi tidak menyakitkan

Saya tidak terlalu tertarik dengan migrasi. saya mencari apa yang dijanjikan di sini (orang-orang ini _definitely_ memiliki orang pemasaran): https://code.fb.com/web/yarn-a-new-package-manager-for-javascript/

Ini memiliki set fitur yang sama dengan alur kerja yang ada saat beroperasi lebih cepat, lebih aman, dan lebih andal.

benang hari ini bukan itu.

AFAICT ada 4 kelas pengguna di sini:

• mereka yang _hanya_ menggunakan benang dalam proyek mereka,
• mereka yang membeli promosi penjualan facbook (di atas) tetapi belum mengalami masalah kunci ini,
• mereka yang dengan susah payah mencoba mengatasi ketidakcocokan dengan secara manual mengonversi file kunci bila perlu, atau menggunakan peretasan lain untuk membuatnya berfungsi,
• mereka yang baru saja menyerah pada benang dan beralih kembali ke npm.

Saya benar-benar tidak ingin berada di kategori terakhir, tetapi sepertinya di situlah saya didorong.

@Spongman, apa yang menghentikanmu dari yang terakhir itu? Kami mungkin bisa memperbaikinya;)

@Spongman Saya tidak berafiliasi dengan Yarn, jadi saya rasa saya bisa sedikit lebih blak-blakan: tidak ada gunanya menyatakan dalam masalah ini bahwa menurut Anda kata-katanya salah. Jika menurut Anda kata-katanya salah, buka halaman itu di GitHub, klik tombol Edit, dan kirimkan permintaan tarik dengan kata-kata yang lebih baik. Arcanis menjelaskan di atas bahwa mereka terbuka untuk itu.

(Saya rasa Anda mungkin tidak dapat mengedit postingan blog, tetapi situs webnya mungkin yang paling penting di sini.)

Saya dapat melihat dari tanggapan @imsnif dan @arcanis bahwa posisi resmi di sini tampaknya adalah bahwa Yarn "tidak pernah dimaksudkan" untuk terus bekerja dengan mulus bersama NPM.

Tapi saya sangat setuju dengan @Spongman bahwa ini adalah kesan yang diberikan Yarn, dan menurut saya itu bukan kecelakaan pada saat itu. Itu adalah kejeniusannya - Anda dapat meningkatkan kecepatan, keamanan, dll. Sambil tetap sepenuhnya mendukung standar NPM resmi.

Dalam kedua kasus, masalah ini membuat posisi Yarn dalam hal ini jauh lebih jelas bagi saya daripada sebelumnya, dan tentu saja, pengelola Yarn dapat memilih untuk mengambilnya ke arah mana pun yang mereka pilih.

Tapi saya pikir Anda secara drastis meremehkan jumlah orang yang menggunakan Yarn justru karena mereka percaya itu mempertahankan kompatibilitas dengan NPM (di tingkat proyek), dan tidak akan pernah beralih sebaliknya. Saya percaya bahwa 254: +1: s dan 10: heart: s di https://github.com/yarnpkg/yarn/issues/3614 dan 57 suara positif pada " Haruskah saya melakukan yarn.lock dan package-lock.json file? "membuat ini sangat jelas.

Jika Yarn melepaskan tanggung jawab apa pun di bagian depan itu, saya pikir itu akan kehilangan tidak hanya @Spongman dan tim saya, tetapi banyak lagi lainnya.

Terus terang saya benar-benar tidak mengerti masalah yang Anda hadapi dengan hanya menggunakan Benang, atau hanya npm. Apa yang Anda katakan pada dasarnya adalah "hei, saya tidak bisa memaksa tim saya untuk menggunakan Yarn, jadi saya akan memaksa mereka untuk menggunakan npm". Itu tidak masuk akal bagiku. Jika Anda menggunakan fitur Yarn maka buat semua orang menggunakan Yarn, dan jika Anda ingin menggunakan fitur npm, maka buat semua orang menggunakan npm. Sesederhana ini.

Setiap inbetween berarti setidaknya build Anda tidak konsisten di seluruh tim Anda, yang bertentangan dengan premis Yarn, seperti yang disebutkan sebelumnya. Salah satu teknisi Anda dapat mulai menggunakan ruang kerja, dan itu akan berhasil, tetapi akan berhenti pada npm. Sama dengan cermin offline. Sama untuk resolusi dependensi. Lebih buruk lagi, karena beberapa bidang sama sekali tidak dikenal oleh npm, itu diam-diam akan melakukan hal yang salah.

Sedangkan untuk komunikasi, posting blog fb tidak menyebutkan pengganti drop-in. Izinkan saya mengutip bagian di mana Yarn diperkenalkan. Ini secara harfiah mengatakan bahwa itu menggantikan alur kerja. Saya rasa Anda bingung dengan "tetap kompatibel dengan registri npm", yang merupakan poin yang adil yang harus Anda bawa ke npm, bukan kepada kami (ada npm cli, registri npm, dan tentu saja npm Inc itu sendiri).

Yarn adalah manajer paket baru yang menggantikan alur kerja yang ada untuk klien npm atau manajer paket lainnya sambil tetap kompatibel dengan registri npm.

apa yang menghentikanmu dari yang terakhir itu? Kami mungkin bisa memperbaikinya;)

@zkat Itu membantu, terima kasih.

@nottrobin - Saya tidak dapat berbicara tentang niat asli benang karena saya tidak ada pada saat itu. Namun saya bekerja di lingkungan benang campuran / npm dengan beberapa lusin repositori.

Saya dapat mengatakan bahwa sangat jelas bagi semua pengembang yang terlibat saat itu bahwa pilihan benang / npm adalah pilihan per-repo, seperti pilihan express / hapi, mobx / redux, dll. Ini menjadi lebih jelas seperti npm @ 5 keluar dengan format file kunci sendiri dan beberapa pengembang memutuskan untuk mulai menggunakannya dengan repositori baru.

Ketika pengembang memasang ketergantungan dengan alat yang salah, itu akan membuat kekacauan bahkan sebelum npm @ 5 , karena ketergantungan itu tidak akan dikunci secara konsisten. Itu menyebabkan masalah di berbagai lingkungan kami dan sangat jelas bagi semua yang terlibat bahwa ini adalah kesalahan *.

Saya menyadari ini mungkin membingungkan - dan saya mengerti ini mungkin tidak 100% jelas bagi semua orang bukan karena kesalahan mereka sendiri, tetapi saya merasa tidak benar untuk mengubah alat secara drastis agar sesuai dengan kesalahpahaman itu. Cara saya melihatnya, benang adalah penurunan pengganti npm pada basis per-repo daripada per-kotak.

* Memang, situasi tertentu dari beberapa repo non-ruang kerja dengan perkakas benang campuran / npm tidak ideal pada tingkat Manusia daripada pada tingkat teknologi untuk potensi kesalahan tersebut dan pada akhirnya diperbaiki. Saya menggunakan contoh ini di sini untuk menunjukkan bahwa dua alat dapat bekerja berdampingan jika didekati dengan benar.

Terus terang saya benar-benar tidak mengerti masalah yang Anda hadapi dengan hanya menggunakan Benang, atau hanya npm.

Ya, Anda @arcanis dan @imsnif telah menjelaskan bahwa Anda tidak mengerti. Satu-satunya poin yang saya buat adalah bahwa banyak orang (lihat: +1: s) membuat interpretasi "salah" yang sama dan ingin Yarn bekerja bersama NPM, terlepas dari apakah Anda memahaminya atau tidak. Jika Benang bukan alat untuk kita, biarlah.

(Hanya satu poin terakhir - @imsnif sangat konyol untuk membandingkan alat untuk menginstal dependensi Node dengan pilihan proyek seperti express vs hapi, mobx vs redux. Itu adalah karakteristik dasar aplikasi Anda. Jika Anda tidak dapat melihat perbedaan yang jelas, tidak heran Anda tidak mengerti maksud saya.)

Bagaimanapun, saya sudah selesai sekarang. Saya pikir saya telah menyampaikan maksud saya sebaik mungkin.

Untuk proyek open source, tidak pernah ada pertanyaan tentang memaksa "tim" untuk menggunakan benang atau npm. Ini pertanyaan tentang apa yang paling nyaman bagi semua orang. Di dunia nyata, npm adalah raja, kecuali jika benang bisa bermain bagus di dunia npm, maka benang itu mati.

^ Ini

Saya khawatir itu juga kesalahpahaman. Selama setahun terakhir, Yarn berubah dari 20% dari jumlah total permintaan ke registri npm menjadi 40% di bulan April . Terakhir kali saya mendengar statistik (langsung dari orang-orang npm, karena statistik kami baru-baru ini rusak ketika registri npm beralih ke Cloudflare), itu adalah sekitar 48% dari permintaan. Di dunia nyata sebenarnya, Benang dan npm hidup berdampingan, polos dan sederhana.

Sekarang saya akan menghargai jika kita dapat kembali ke topik yang sedang dibahas, yaitu: siapa yang bersedia menulis PR untuk menulis peringatan ketika kita mendeteksi file package-lock.json pada saat penginstalan? Terima kasih.

Ssst , https://github.com/yarnpkg/yarn/pull/5920

Luar biasa: heart_eyes:

Antara ini dan pekerjaan Anda pada yarn import , dapatkah kita menutup masalah ini?

Saya pikir kami akan menunggu @jmorrell untuk memberi kami beberapa statistik tentang bagaimana ini memengaruhi masalah di Heroku sehingga kami dapat memutuskan apakah ini cukup atau kami ingin mengubah sesuatu (peringatan / kesalahan, dll.) Wdyt?

EDIT: afaik peringatannya belum dirilis, jadi kami masih punya waktu untuk menunggu.

Saya khawatir itu juga kesalahpahaman.

Bagaimana? Volume lalu lintas di npm tidak memberi tahu Anda tentang apakah proyek tersebut open source atau tidak.

penilaian yang lebih akurat adalah menghitung proyek github mana yang memiliki 0,1 atau 2 (yarn.lock, package-lock.json). secara pribadi saya telah _never_ melihat proyek open-source (dengan ukuran yang cukup besar) di github yang memiliki file yarn.lock dan _no_ package-lock.json (kecuali yang sudah jelas).

IMO jika Anda ingin menyimpan file kunci terpisah, maka KEDUA pengelola paket harus mendeteksi file kunci dan ERROR orang lain (mungkin dengan tanda override).

Semua - Saya dengan hormat meminta agar kami tetap pada topik dan mengambil komentar yang tidak terkait langsung secara offline (misalnya saluran Discord kami). Ada banyak orang yang berlangganan utas ini dan sejujurnya, saya merasa diskusi utas npm <> tidak termasuk di sini. Terima kasih!

Saya belum membaca keseluruhan tapak, tetapi pengguna IHMO setidaknya harus diberi tahu bahwa ada ambiguitas:

jika npm melihat file yarn.lock maka npm harus mencetak sesuatu seperti:
PERINGATAN: proyek ini sepertinya menggunakan benang, mungkin Anda harus menggunakan 'benang' daripada 'npm install' "

jika benang melihat file package-lock.json maka benang harus mencetak sesuatu seperti:
"PERINGATAN: proyek ini sepertinya menggunakan npm, mungkin Anda harus menggunakan 'npm install' daripada 'yarn'"

Dan seperti yang disarankan di atas, cara untuk "memilih" pengelola paket (di package.json).

Saya dapat mengatakan bahwa sangat jelas bagi semua pengembang yang terlibat saat itu bahwa pilihan benang / npm adalah pilihan per-repo, seperti pilihan express / hapi, mobx / redux, dll.

Ini sama sekali tidak jelas bagi saya. Hingga saat ini saya pikir itu adalah pilihan pengembang-lokal, dan banyak pengembang dapat hidup berdampingan dalam satu repo menggunakan mana saja yang mereka suka, sementara itu _a sedikit lebih nyaman_ untuk menggunakan hanya satu secara konsisten. Contoh express / hapi dll bagus dan menjelaskan bahwa itu bukan pilihan. Ini harus memiliki lebih banyak visibilitas.

Tambahkan bidang di package.json untuk menunjukkan pengelola paket mana yang harus digunakan proyek

"package-manager": "yarn"

Saya rasa ini adalah solusi terbaik, jika diterapkan di semua manajer paket.

Manajer paket kemudian HARUS 100% menolak untuk melanjutkan jika mereka dipanggil pada proyek yang salah, sama seperti Anda akan mengharapkan kesalahan jika Anda membutuhkan redux tetapi kemudian mencoba memanggil fungsi mobx di dalamnya. Mereka harus mengeluarkan kesalahan, bukan peringatan, dan memberi tahu pengguna bagaimana melanjutkan dengan manajer paket yang benar.

Tambahkan bidang di package.json untuk menunjukkan pengelola paket mana yang harus digunakan proyek
"package-manager": "yarn"

Saya rasa ini adalah solusi terbaik, jika diterapkan di semua manajer paket.

Jika Anda ingin npm mempertimbangkan hal ini, saya mendorong Anda untuk membuka diskusi di tempat yang sesuai , tetapi saya akan mengatakan bahwa saya tidak menyukai arahan ini. Saya ingin melihat konvergensi antara manajer paket, bukan divergensi.

Saya akan merekomendasikan terhadap beberapa bidang "manajer paket" baru, sebagai gantinya merekomendasikan stanza engines yang sudah ada yang sudah memiliki seni sebelumnya.

Baik benang maupun dokumen npm menyebutkan (sambil lalu) penggunaan engines.npm dan engines.yarn untuk menentukan versi masing-masing yang diharapkan akan digunakan. Benang bahkan akan error jika versi benang tidak memenuhi engines.yarn .

https://yarnpkg.com/en/docs/package-json#engines -
https://docs.npmjs.com/files/package.json#engines

Bahkan jika npm atau benang tidak memeriksa engines untuk manajer "bersaing" (yang akan menyenangkan), menggunakan bidang ini masih merupakan cara yang bagus untuk berkomunikasi dengan pengembang lain manajer mana yang diharapkan untuk digunakan. (jika keberadaan package-lock.json atau yarn.lock tidak cukup sebagai petunjuk)

Saya ingin melihat konvergensi antara manajer paket, bukan divergensi.

Sepakat. Entah konvergensi, atau penolakan.

tetapi jalan tengah yang ambigu dan keliru saat ini berbahaya.

Saya masih berpikir bahwa hanya melempar kesalahan di hadapan lockfile orang lain akan membutuhkan paling sedikit gesekan untuk proyek yang ada.

Jika Anda ingin npm mempertimbangkan hal ini, saya mendorong Anda untuk membuka diskusi di tempat yang sesuai

Terima kasih, saya baru saja mendaftar. Ada utas terbaru ke arah ini: https://npm.community/t/npm-install-should-warn-about-the-presence-of-yarn-lock-files/1822

Pilihan saya adalah untuk membuat kesalahan berhenti penuh daripada hanya memberi peringatan, jadi tidak yakin apakah saya harus menambahkan utas itu untuk memulai yang baru.

Saya ingin melihat konvergensi antara manajer paket, bukan divergensi.

Sama disini. Meskipun mereka tidak kompatibel sekarang, jadi perbedaan telah terjadi dan telah menyebabkan gesekan pada banyak pengguna dan proyek.

Apa pun konvergensi yang dihasilkan dari pembicaraan lebih lanjut di antara tim akan membutuhkan waktu. Ketika itu benar-benar tiba, kesalahan yang diusulkan dapat diangkat dan pengguna dapat mulai beralih dan menggabungkan manajer paket tanpa kesulitan.

Menambahkan kesalahan sekarang menghindari kebingungan lebih lanjut dan tidak menghentikan upaya ke arah konvergensi.

Saya akan merekomendasikan terhadap beberapa bidang "manajer paket" baru, sebagai gantinya merekomendasikan stanza mesin yang ada yang sudah memiliki seni sebelumnya.

Kedengarannya masuk akal. Saya tidak terikat pada metode tertentu untuk mendeteksi keberadaan pengelola paket yang tidak kompatibel.

Untuk menambahkan ilustrasi, kasus penggunaan saya khususnya adalah gatsbyjs. Situasinya sama persis dengan yang dilaporkan oleh @gaearon di sini :

Untuk Membuat pengguna React App, ini sangat membingungkan karena proyek mereka dibuat dengan Yarn (jika Yarn ada di sistem) tetapi kemudian mereka mengikuti dokumen dari beberapa perpustakaan yang memberitahu mereka untuk menginstal npm, dan itu menghancurkan seluruh pohon.

Untuk menghindari masalah ini, meskipun gatsby menggunakan benang, ia juga menambahkan package-lock.json ke permulaan default . Tapi kemudian pengguna berakhir dengan kedua file kunci dan mulai melihat peringatan. Sangat mudah untuk hanya menghapus salah satu dari mereka, tetapi itu mengacaukan pengalaman orientasi.

Terima kasih semuanya atas masukan Anda.

@jmorrell - https://github.com/yarnpkg/yarn/pull/5920 dirilis di 1.9.2 pada Jul 25. Sudah lebih dari sebulan, saya tahu ini bukan waktu yang lama (dan tentunya tidak semua orang telah meningkatkan) - tetapi apakah Anda mungkin memiliki beberapa wawasan untuk dibagikan terkait kesalahan penguncian ganda di Heroku sejak saat itu?

@imsnif Terima kasih atas pengingat email! Maaf untuk melewatkan pembaruan di sini.

Berikut adalah grafik jumlah aplikasi yang mengalami kegagalan khusus ini setiap minggu di tahun 2018.

(Saya telah menyunting skala y, tapi ini mewakili 100-an pengembang dan menunjukkan tren)

1. Penurunan di bulan Juli berasal dari masalah yang tidak terkait dengan S3

2. Melihat tren setelah tanggal 25 Juli, peringatan tersebut tampaknya memiliki pengaruh yang substansial terhadap jumlah orang yang mengalami kesalahan ini. Saya agak terkejut dengan besarnya pergeseran tersebut.

@jmorrell - ini benar-benar hebat!
Saya akui saya juga cukup terkejut dengan ini.

Saya pikir (di sisi benang) masalah ini dapat dianggap diselesaikan. Apa kamu setuju?

saya masih berpikir saran untuk menghapus package-lock.json untuk memperbaiki kesalahan itu menyesatkan - ini secara umum akan menghasilkan rangkaian versi paket yang berbeda yang digunakan, dan akan (sekali lagi, secara umum) menyebabkan ketidakcocokan dan kerusakan. Selain itu, saran ini hanya berguna bagi mereka yang membuat keputusan tentang manajer paket mana yang digunakan proyek. kontributor umum yang mengikuti saran ini juga akan mengetahui masalah.

IMO jika package-lock.json ada dan yarn tidak dapat menjamin bahwa versi yang dipasangnya sama dengan versi yang akan dipasang npm , maka seharusnya gagal dengan kesalahan .

Terima kasih sekali lagi atas masukan Anda @Spongman. Saya merasa ini semua telah dibahas dengan baik di utas (sangat panjang) di atas kita dan menurut saya tidak masuk akal untuk memulai ulang lagi. Saya pikir kita semua memahami posisi Anda. Terima kasih telah berpartisipasi.

Kecuali @jmorrell memberi tahu saya sebaliknya dalam minggu depan atau lebih, saya akan mempertimbangkan ini selesai dan menutup masalah ini.

@imsnif Mengambil jalur yang berbeda dan melihat kegagalan dari September sejauh ini (1 Sep - 20 Sep), ini masih menjadi alasan nomor 1 mengapa Node dibangun di atas Heroku. Ini terjadi dua kali lebih banyak dari kasus kegagalan paling umum berikutnya yang diketahui: package.json menjadi JSON tidak valid. Sekali lagi menyunting angka pasti, berikut ini cara menyusunnya ke masalah lain.

Saya belum melihat pergerakan apa pun dari npm dalam hal ini, jadi saya akan membuat PR menambahkan peringatan di sana juga dan melihatnya diterima.

Saya pikir (di sisi benang) masalah ini dapat dianggap diselesaikan. Apa kamu setuju?

Saya rasa ini belum diselesaikan untuk pengguna, dan pengalaman pengguna masih belum bagus. Tetapi saya dapat melihat bagaimana angkanya berubah setelah npm juga memberikan umpan balik kepada pengguna yang melakukan kasus ini.

Terserah Anda apakah Anda ingin menutup ini atau membuat perubahan lebih lanjut. Saya dengan senang hati membuka masalah baru dalam beberapa bulan jika ini masih menjadi masalah besar bagi pengguna.

@jmorrell - mengingat masalah ini menarik banyak perhatian dan percakapan terus dimulai ulang dan bahkan berulang, saya pikir akan lebih baik untuk menutupnya sekarang dengan informasi yang kami miliki.

Jika, dengan npm memberikan peringatan juga, kami masih melihat masalah, saya pasti bersedia untuk memulai diskusi kesalahan lagi (atau mencari solusi lain). Tolong, lakukan ping saya secara pribadi dalam kasus itu.

Terima kasih telah mengungkit hal ini, berkontribusi, dan membuat semua perubahan ini terjadi! Saya pribadi merasa benang lebih baik setelah masalah ini.