Yarn: Haruskah saya memasukkan yarn.lock di .gitignore?

Anda harus menambahkan yarn.lock ke git Anda , jangan abaikan.

Lihat https://yarnpkg.com/en/docs/migrating-from-npm

Saat Anda menjalankan yarn atau yarn add <package> , Yarn akan menghasilkan file yarn.lock di dalam direktori root paket Anda. Anda tidak perlu membaca atau memahami file ini - cukup periksa ke source control . Ketika orang lain mulai menggunakan Yarn alih-alih npm , file yarn.lock akan memastikan bahwa mereka mendapatkan dependensi yang sama persis seperti yang Anda miliki.

Untuk memperjelas - ini juga berlaku untuk perpustakaan dan bukan hanya aplikasi, karena berlawanan dengan npm-shrinkwrap.json hanya yarn.lock dari proyek tingkat atas yang akan digunakan, bukan? Jadi dependensi dependensi dengan file yarn.lock tidak akan menghasilkan duplikat yang tidak perlu. Ini berguna untuk perpustakaan, jika Anda memiliki dependensi pengembang yang kompleks dan Anda ingin setiap kontributor perpustakaan Anda memiliki konfigurasi build dan pengujian yang sama.

Apakah ini benar?

@goenning
Mungkin tidak selalu merupakan ide terbaik untuk meletakkan file yarn.lock di repositori Anda.
Misalnya saya menggunakan sinopia. Oleh karena itu saya memiliki registri npm khusus. Saya menggunakan registri ini terutama untuk proyek lain di mana saya memiliki modul pribadi.
Tetapi ketika saya mendorong proyek publik ke repositori git, yang hanya memiliki dependensi publik, yarn.lock memiliki tautan yang salah ke dependensi dan sistem CI saya akan gagal membangun proyek.
Ketergantungan menunjuk ke repositori lokal saya.
Ini juga dapat terjadi pada pengembang lain jika mereka mengkloning repositori saya.
Apakah ada cara untuk menyiasatinya kecuali memasukkan file yarn.lock ke dalam gitignore?

Juga, jika Anda memiliki registri npm yang telah diautentikasi sebelumnya, misalnya myget yang proksinya ke npm, yarn.lock akan memiliki tautan yang diautentikasi sebelumnya ke paket, yang merupakan pelanggaran keamanan utama
Ini harus didokumentasikan di suatu tempat dengan font besar.

@Pfeifenjoy bagaimana jika Anda menautkan ke paket pribadi menggunakan git submodule alih-alih npm?
menggunakan git, Anda dapat mengakses repo menggunakan kunci penyebaran (via ssh)

@beenotung Saya bukan penggemar berat menggunakan git sebagai manajer ketergantungan, karena sangat lambat, tidak menyelesaikan dependensi seperti yang saya inginkan untuk diselesaikan dan menurut saya yang terbaik adalah memiliki setiap ketergantungan dalam satu manajer.

Juga ketergantungan yang saya rujuk akan semua (tidak hanya proyek saya sendiri) mendapatkan alamat yang berbeda, karena mereka disimpan di akun sinopia lokal saya. Akan sangat membosankan untuk mereferensikan semua modul simpul yang bergantung pada proyek saya di git.
Selain itu, lebih mudah untuk menghapus file yarn.lock.

@Pfeifenjoy Apakah mungkin ada konflik dalam apa yang Anda ingin benang lakukan? Jika Anda ingin memberikan cara untuk memastikan instalasi lain memiliki dependensi Anda, sertakan itu- itu berfungsi sebagaimana dimaksud. Jika Anda menarik repo dan sumber pribadi, Anda harus sangat berhati-hati tentang bagaimana Anda membagikan kode Anda per-katakan, dengan cara yang sama seperti Anda secara khusus akan mengabaikan kunci atau garam apa pun dari repo (jika Anda ingin melihat peringatan pada readme proyek, saya akan membuat permintaan fitur/tarik).

Mungkin benang harus memberikan peringatan saat menjalankan memperingatkan pengguna bahwa akses ke sumber yang diautentikasi telah disertakan dalam file kunci, tetapi sekali lagi, itu akan menjadi permintaan fitur.

@thisolivier terdengar masuk akal

Hanya sebuah memo.
Karena https://github.com/yarnpkg/yarn/issues/3330 , jika Anda tinggal di Cina atau area terlarang lainnya, dan membangun modul Anda dengan registri lain (eq taobao), Anda harus menambahkan yarn.lock ke .gitignore dan tulis package-lock = false ke .npmrc.

Di sini mengapa saya tidak melakukan yarn.lock saya : beberapa modul memiliki dependensi asli dan hanya akan bekerja untuk beberapa platform ( platform yang persis sama dengan tempat yarn.lock dihasilkan ).
untuk membuat pengguna saya senang dan instalasi bebas bug, saya menghapus benang - kecuali jika benang memberikan solusi dengan dokumentasi yang jelas bagaimana menyelesaikannya, saya akan setuju.
(selalu dengar dari pengembang kisah nyata)

Juga itu membuat komitmen Anda sangat jelek.

Saya tidak setuju dengan komentar yang paling banyak dipilih di sini:

• jika proyek menggunakan npm, komit package-lock.json ke repo dan gitignore yarn.lock
• jika proyek menggunakan benang, komit yarn.lock ke repo dan gitignore package-lock.json

Artinya, Anda harus _not_ selalu melakukan yarn.lock ke repo , dan untuk menjawab pertanyaan OP, ya Anda mungkin ingin menambahkannya ke .gitignore .

Ketika orang lain mulai menggunakan Yarn alih-alih npm, file yarn.lock akan memastikan bahwa mereka mendapatkan dependensi yang sama persis seperti yang Anda miliki

Pertama, tidak akan - hanya jika Anda hanya pernah menggunakan registri npm publik. Lebih buruk jika Anda tidak diautentikasi ke org pribadi Anda di benang, (bahkan jika Anda masih menggunakan npm), dan paket dengan nama yang sama ada di registri publik, itu hanya akan menginstal yang salah tanpa Prompt. Akan membingungkan mengapa benang Anda dipasang tanpa kesalahan, namun aplikasi tidak berfungsi saat menggunakan benang namun saat menggunakan npm.

Kedua, banyak basis kode _don't_ menggunakan benang. Ini bukan masalah "ketika mereka beralih ke benang". Hampir semua layanan simpul & server web dasar saya menggunakan npm tanpa rencana untuk pindah ke benang. Saya suka benang dengan React, itu saja.

Seperti yang disebutkan @Pfeifenjoy di atas:

Saya memiliki registri npm khusus. Saya menggunakan registri ini terutama untuk proyek lain di mana saya memiliki modul pribadi

Tetapi ketika saya mendorong proyek publik ke repositori git, yang hanya memiliki dependensi publik, yarn.lock memiliki tautan yang salah ke dependensi dan sistem CI saya akan gagal membangun proyek.

^ Hal lain, bahkan ketika Anda menyelesaikannya secara lokal, Anda harus memasukkan solusi ke dalam yaml atau konfigurasi apa pun untuk CI & di mana pun Anda memutar aplikasi - semacam logika yang dapat memberi tahu kapan harus menggunakan registri mana dan perintah mana - terdengar menjengkelkan dan tidak perlu

Hal lain - jika Anda mendorong semua orang untuk selalu melakukan yarn.lock ke repo dan tidak pernah mengabaikannya, pengembang akan mulai menggunakan benang dalam repo yang sudah sangat bergantung pada npm. Bahkan dalam kasus di mana itu berfungsi dengan baik, akan ada redundansi dalam 2 file kunci, dan itu akan membuka pintu ke neraka ketergantungan. Dan Anda tahu beberapa pengembang akan melakukan ~25k baris yarn.lock di beberapa titik mengacaukan grafik kontribusi Anda :joy: