Yarn: Haruskah yarn.lock diperlakukan sebagai file biner di git?

Tidak seharusnya. File adalah teks biasa dan mungkin ada konflik gabungan dalam file yang mungkin perlu Anda selesaikan.

Dalam dokumentasi tertulis bahwa file yarn.lock tidak boleh disentuh untuk menghindari masalah dan hanya benang itu sendiri yang harus menanganinya. Lalu bagaimana cara mengatasi konflik gabungan?

@kittens adalah hal yang benar untuk dilakukan ketika ada konflik untuk menerbangkan file kunci dan menjalankan kembali benang? Menurut saya itu akan mendapatkan apa yang Anda butuhkan?

@dbashford masalah dengan meniupnya dan menjalankan kembali benang adalah Anda akan mendapatkan lebih banyak perubahan daripada yang Anda inginkan. Misalnya, versi tilde akan ditingkatkan, meskipun Anda tidak menjalankan yarn upgrade .

@dbashford maka lebih mudah untuk meletakkan benang. kunci file di gitignore

Pendekatan yang berhasil bagi saya sejauh ini adalah ini:

git rebase origin/master

Ketika konflik pertama muncul, saya checkout yarn.lock kemudian melakukan instalasi ulang

git checkout origin/master -- yarn.lock
yarn install

Ini menghasilkan yarn.lock berdasarkan versi Origin/master dari yarn.lock , tetapi termasuk perubahan yang saya buat pada package.json . Maka itu hanya masalah:

git add yarn.lock
git rebase --continue

Dan saya kembali berbisnis.

Perhatikan bahwa meskipun Anda tidak menyelesaikan konflik gabungan secara manual, menjadikannya file non-biner berarti Anda dapat melihat konflik gabungan, yang masih merupakan informasi berharga.

Terkait, bahkan jika ada _no_ konflik penggabungan, dapatkah kita selalu berasumsi bahwa git telah menggabungkan dua versi file yarn.lock sedemikian rupa sehingga menghasilkan file yang valid/benar? Tampaknya salah untuk membiarkan git memperbarui konten file sama sekali jika benang adalah satu-satunya alat yang seharusnya mengelola kontennya.

Saya tidak yakin bahwa penggabungan otomatis YAML akan selalu menghasilkan file yang valid, terutama mengingat:

• Beberapa versi utama dalam paket yang berada tepat di sebelah satu sama lain di lockfile
• Baris pertama dari dua entri tetangga dapat berubah pada saat yang sama saat menyelesaikan ke versi yang sama atau serupa:

readable-stream@^2.0.0, "readable-stream@^2.0.0 || ^1.1.13", readable-stream@^2.0.2, readable-stream@^2.0.5, readable-stream@^2.2.2:
  version "2.2.2"
  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.2.2.tgz#a9e6fec3c7dda85f8bb1b3ba7028604556fc825e"
  dependencies:
    buffer-shims "^1.0.0"
    core-util-is "~1.0.0"
    inherits "~2.0.1"
    isarray "~1.0.0"
    process-nextick-args "~1.0.6"
    string_decoder "~0.10.x"
    util-deprecate "~1.0.1"

readable-stream@~2.1.4:
  version "2.1.5"
  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.1.5.tgz#66fa8b720e1438b364681f2ad1a63c618448c9d0"
  dependencies:
    buffer-shims "^1.0.0"
    core-util-is "~1.0.0"
    inherits "~2.0.1"
    isarray "~1.0.0"
    process-nextick-args "~1.0.6"
    string_decoder "~0.10.x"
    util-deprecate "~1.0.1"

@IanVS Terima kasih atas kekhawatiran @idris masih berlaku untuk solusi ini. Anda akhirnya akan meningkatkan banyak dependensi Anda dengan cara ini, yang mungkin tidak terduga.

@danny-andrews dapatkah Anda menjelaskan caranya?

Saat Anda menghapus yarn.lock dan menjalankan kembali yarn install , seluruh yarn.lock akan dibangun kembali dengan versi dependensi terbaru yang memenuhi rentang versi yang ditentukan dalam package.json , secara efektif memutakhirkan ketergantungan apa pun yang telah berubah sejak terakhir dijalankan yarn install .

Itu sebabnya saya menyarankan git checkout origin/master -- yarn.lock daripada menghapus yarn.lock . Itu akan mengatur ulang yarn.lock ke versi pada master, memungkinkan yarn install untuk memperbarui hanya paket yang telah berubah di package.json (dan sub-depnya, tentu saja) .

@IanVS ya, itu adalah cara yang benar untuk melakukannya.

Meskipun saya akan merekomendasikan git checkout -- yarn.lock , yang lebih umum dan hanya mengatur ulang ke apa pun yang dilakukan pada cabang Anda saat ini.

Poin bagus, @idris. Saya biasanya rebase ke master, yang merupakan contoh yang saya gunakan di atas, tetapi itu tidak akan selalu terjadi.

@IanVS Saya tidak mengerti apa yang dilakukan perintah itu. Itu jauh lebih baik daripada menyalin dan menempelkan yarn.lock secara manual seperti yang telah saya lakukan. Terima kasih telah berbagi!

Ini terkait: #3544

Bukankah pendekatan @IanVS kompatibel dengan membuat lockfile menjadi file biner? Jika saya mengerti dengan benar bahwa idenya adalah untuk tidak pernah menggabungkan, buang saja apa yang Anda miliki dan putar ulang yarn install di atas yarn.lock yang sudah ada di cabang tempat Anda bergabung.

inilah pendekatan saya, untuk menambahkan skrip bash

#!/usr/bin/env bash
export GIT_TRACE=1
git checkout origin/master -- Pipfile.lock Pipfile
git commit -m "fetch to branch Pipfile.lock, Pipfile from origin/master" -- Pipfile.lock Pipfile
read  -n 1 -p "Do your changes in Pipfile and press Enter ..."
pipenv lock --clear
git commit -m "re-apply changes to Pipfile.lock, Pipfile" -- Pipfile.lock Pipfile
echo "Done"