Haruskah composer.lock dikomit ke kontrol versi?

Saya agak bingung dengan yang composer.lockdigunakan dalam aplikasi dengan repositori.

Saya melihat banyak orang mengatakan bahwa kita tidak boleh .gitignore composer.lockdari repositori.

Jika saya memperbarui perpustakaan di lingkungan dev saya, saya akan memiliki yang baru composer.locktetapi saya tidak akan dapat memperbaruinya menjadi produksi, bukan?

Tidakkah akan menghasilkan konflik pada file ini?

Jika Anda memperbarui lib Anda, Anda juga ingin mengkomit lockfile. Ini pada dasarnya menyatakan bahwa proyek Anda dikunci ke versi spesifik lib yang Anda gunakan.

Jika Anda mengkomit perubahan Anda, dan seseorang menarik kode Anda dan memperbarui dependensi, file kunci harus tidak dimodifikasi. Jika dimodifikasi, itu berarti Anda memiliki versi sesuatu yang baru.

Setelah itu dalam repositori meyakinkan Anda bahwa setiap pengembang menggunakan versi yang sama.

Untuk aplikasi / proyek : Pasti ya.

The dokumentasi komposer menyatakan pada ini (dengan penekanan):

Komit composer.lock aplikasi Anda (bersama dengan composer.json) ke dalam kontrol versi.

Seperti @meza berkata: Anda harus melakukan file kunci sehingga Anda dan kolaborator Anda bekerja pada set versi yang sama dan mencegah Anda dari ucapan seperti "Tapi itu berhasil di komputer saya". ;-)

Untuk perpustakaan : Mungkin tidak.

Dokumentasi komposer mencatat tentang masalah ini:

Catatan: Untuk perpustakaan, tidak selalu disarankan untuk melakukan file kunci (...)

Dan nyatakan di sini :

Untuk perpustakaan Anda, Anda dapat melakukan file composer.lock jika Anda mau. Ini dapat membantu tim Anda untuk selalu menguji terhadap versi ketergantungan yang sama. Namun, file kunci ini tidak akan berpengaruh pada proyek lain yang bergantung padanya. Ini hanya berpengaruh pada proyek utama.

Untuk perpustakaan saya setuju dengan jawaban @Josh Johnson.

Setelah melakukan kedua cara itu untuk beberapa proyek, pendirian saya adalah yang composer.locktidak boleh dilakukan sebagai bagian dari proyek.

composer.lockadalah membangun metadata yang bukan bagian dari proyek. Keadaan dependensi harus dikontrol melalui cara Anda memvariasikannya (baik secara manual atau sebagai bagian dari proses pembuatan otomatis Anda) dan tidak sewenang-wenang oleh pengembang terakhir untuk memperbaruinya dan melakukan file kunci.

Jika Anda khawatir tentang ketergantungan Anda berubah di antara pembaruan komposer maka Anda kurang percaya diri pada skema versi Anda. Versi (1.0, 1.1, 1.2, dll) harus tidak berubah dan Anda harus menghindari wildcard "dev-" dan "X. *" di luar pengembangan fitur awal.

Mengkomit file penguncian adalah regresi untuk sistem manajemen dependensi Anda karena versi dependensi sekarang telah kembali ke yang didefinisikan secara implisit.

Juga, proyek Anda seharusnya tidak harus dibangun kembali atau ketergantungannya diperoleh kembali di setiap lingkungan, terutama prod. Hasil kerja Anda (tar, zip, phar, direktori, dll) harus tidak berubah dan dipromosikan melalui lingkungan tanpa perubahan.

1. Anda tidak harus memperbarui dependensi Anda secara langsung pada Produksi.
2. Anda harus mengontrol versi file comper.lock Anda .
3. Anda seharusnya tidak mengontrol versi dependensi Anda yang sebenarnya.

1. Anda seharusnya tidak memperbarui dependensi Anda secara langsung pada Production , karena Anda tidak tahu bagaimana ini akan mempengaruhi stabilitas kode Anda. Mungkin ada bug yang diperkenalkan dengan dependensi baru, mungkin mengubah cara kode berperilaku mempengaruhi Anda sendiri, itu mungkin tidak kompatibel dengan dependensi lain, dll. Anda harus melakukan ini di lingkungan dev, diikuti dengan QA dan pengujian regresi yang tepat, dll .

2. Anda harus mengontrol versi file comper.lock Anda , karena ini menyimpan informasi tentang dependensi Anda dan tentang dependensi dependensi Anda yang akan memungkinkan Anda untuk mereplikasi keadaan kode saat ini. Ini penting, karena, semua pengujian dan pengembangan Anda dilakukan terhadap kode tertentu. Tidak peduli dengan versi kode yang sebenarnya Anda miliki mirip dengan mengunggah perubahan kode ke aplikasi Anda dan tidak mengujinya. Jika Anda meningkatkan versi dependensi Anda, ini harusnya merupakan tindakan sukarela, dan Anda harus berhati-hati untuk memastikan semuanya masih berfungsi. Kehilangan satu atau dua jam dari waktu ke waktu kembali ke versi rilis sebelumnya mungkin dikenakan biaya banyak uang.

Salah satu argumen yang akan Anda lihat tentang tidak memerlukan komposer. Kunci adalah bahwa Anda dapat mengatur versi yang tepat yang Anda butuhkan dalam file composer.json Anda , dan bahwa dengan cara ini, setiap kali seseorang berjalan composer install, itu akan menginstalnya sama kode. Ini tidak benar, karena, dependensi Anda memiliki dependensinya sendiri, dan konfigurasinya mungkin ditentukan dalam format yang memungkinkan pembaruan untuk subversi, atau bahkan mungkin seluruh versi.

Ini berarti bahwa bahkan ketika Anda menentukan bahwa Anda ingin Laravel 4.1.31 di composer.json Anda , Laravel dalam file composer.jsonnya mungkin memiliki dependensi sendiri yang diperlukan sebagai event-dispatcher Symfony: 2. *. Dengan konfigurasi seperti ini, Anda bisa berakhir dengan Laravel 4.1.31 dengan Symfony event-dispatcher 2.4.1, dan orang lain di tim Anda bisa memiliki Laravel 4.1.31 dengan event-dispatcher 2.6.5, semuanya akan tergantung pada kapan adalah kali terakhir Anda menjalankan pemasangan komposer.

Jadi, memiliki file composer.lock Anda dalam sistem versi akan menyimpan versi yang tepat dari sub-dependensi ini, jadi, ketika Anda dan rekan satu tim Anda melakukan pemasangan komposer (ini adalah cara Anda akan menginstal dependensi Anda berdasarkan komposer. mengunci ) Anda berdua akan mendapatkan versi yang sama.

Bagaimana jika Anda ingin memperbarui? Kemudian di lingkungan dev Anda jalankan:, composer updateini akan menghasilkan file composer.lock baru (jika ada sesuatu yang baru) dan setelah Anda mengujinya, dan tes QA dan regresi mengujinya dan sebagainya. Anda dapat mendorongnya untuk orang lain untuk mengunduh komposer baru. Kunci , karena aman untuk ditingkatkan.

3. Anda seharusnya tidak mengontrol versi dependensi Anda yang sebenarnya , karena itu tidak masuk akal. Dengan komposer. Kunci Anda dapat menginstal versi dependensi yang tepat dan Anda tidak perlu mengkomitnya. Mengapa Anda menambah repo 10.000 file dependensi Anda, padahal Anda tidak seharusnya memperbaruinya. Jika Anda perlu mengubah salah satu dari ini, Anda harus membayarnya dan membuat perubahan di sana. Dan jika Anda khawatir harus mengambil dependensi aktual setiap kali membangun atau merilis, komposer memiliki cara berbeda untuk mengatasi masalah ini, cache, file zip, dll.

Anda kemudian berkomitmen composer.jsonuntuk proyek Anda dan semua orang di tim Anda dapat menjalankan komposer menginstal untuk menginstal dependensi proyek Anda.

Inti dari file kunci adalah untuk merekam versi persis yang diinstal sehingga mereka dapat diinstal ulang. Ini berarti bahwa jika Anda memiliki spesifikasi versi 1. * dan rekan kerja Anda menjalankan pembaruan komposer yang menginstal 1.2.4, dan kemudian melakukan file composer.lock, ketika Anda menginstal komposer, Anda juga akan mendapatkan 1.2.4, bahkan jika 1.3.0 telah dirilis. Ini memastikan semua orang yang mengerjakan proyek memiliki versi persis yang sama.

Ini berarti bahwa jika sesuatu telah dilakukan sejak terakhir kali pemasangan komposer dilakukan, maka, tanpa file kunci, Anda akan mendapatkan kode pihak ketiga baru ditarik ke bawah .

Sekali lagi, ini adalah masalah jika Anda khawatir tentang pemecahan kode Anda. Dan itu salah satu alasan mengapa penting untuk menganggap Composer sebagai terpusat di sekitar file composer.lock.

Sumber: Komposer: Semuanya tentang File Kunci .

Komit composer.lock aplikasi Anda (bersama dengan composer.json) ke dalam kontrol versi. Ini penting karena perintah instal memeriksa apakah file kunci ada, dan jika ada, ia mengunduh versi yang ditentukan di sana (terlepas dari apa yang dikatakan composer.json). Ini berarti bahwa siapa pun yang menyiapkan proyek akan mengunduh versi dependensi yang sama persis. Server CI Anda, mesin produksi, pengembang lain di tim Anda, semuanya dan semua orang berjalan pada dependensi yang sama, yang mengurangi potensi bug yang hanya mempengaruhi beberapa bagian dari penyebaran. Bahkan jika Anda mengembangkan sendiri, dalam enam bulan ketika menginstal ulang proyek Anda dapat merasa yakin dependensi yang diinstal masih berfungsi bahkan jika dependensi Anda merilis banyak versi baru sejak itu.

Sumber: Komposer - Penggunaan Dasar .

Jika Anda khawatir tentang pemecahan kode Anda, Anda harus mengkomit composer.lockke sistem kontrol versi Anda untuk memastikan semua kolaborator proyek Anda menggunakan versi kode yang sama. Tanpa file kunci, Anda akan mendapatkan kode pihak ketiga baru ditarik setiap kali.

Pengecualiannya adalah ketika Anda menggunakan aplikasi meta, pustaka tempat dependensi harus diperbarui saat diinstal (seperti Aplikasi Kerangka Zend Framework 2 ). Jadi tujuannya adalah untuk mengambil dependensi terbaru setiap kali ketika Anda ingin mulai berkembang.

^{Sumber: Komposer: Semuanya tentang File Kunci}

Lihat juga: Apa perbedaan antara pembaruan komposer dan pemasangan komposer?

Tidak ada jawaban pasti untuk ini.

Secara umum, komposer tidak boleh melakukan apa yang seharusnya dilakukan oleh sistem build dan Anda tidak boleh memasukkan komposer. Buka di VCS. Komposer mungkin aneh memilikinya mundur. Pengguna akhir alih-alih hasil tidak boleh menggunakan file kunci. Biasanya sistem build Anda menyimpan snapshot, direktori yang dapat digunakan kembali, dll, bukannya direktori kosong setiap kali. Orang-orang checkout lib dari komposer mungkin ingin lib menggunakan kunci sehingga dependensi yang beban lib telah diuji terhadap.

Di sisi lain yang secara signifikan meningkatkan beban manajemen versi, di mana Anda hampir pasti menginginkan beberapa versi dari setiap perpustakaan karena dependensi akan dikunci dengan ketat. Jika setiap pustaka cenderung memiliki versi yang sedikit berbeda maka Anda memerlukan beberapa dukungan versi pustaka dan Anda juga dapat dengan cepat melihat ukuran dependensi yang diperlukan, maka disarankan untuk tetap menggunakannya.

Mengambil hal itu, saya benar-benar tidak menemukan file kunci berguna perpustakaan atau workdir Anda sendiri. Ini hanya digunakan untuk saya adalah di platform build / testing saya yang bertahan setiap aset yang diperoleh secara eksternal hanya memperbarui mereka ketika diminta, memberikan build berulang untuk pengujian, membangun dan menyebarkan. Sementara itu dapat disimpan dalam VCS tidak selalu disimpan dengan pohon sumber, pohon build akan berada di tempat lain dalam struktur VCS atau dikelola oleh sistem lain di tempat lain. Jika disimpan dalam VCS, masih dapat diperdebatkan apakah akan menyimpannya dalam repo yang sama dengan pohon sumber karena jika tidak setiap tarikan dapat membawa banyak aset bangunan. Saya sangat suka memiliki semuanya dalam repo yang diatur dengan baik kecuali produksi / kredensial sensitif dan mengasapi.

SVN dapat melakukannya lebih baik daripada git karena tidak memaksa Anda untuk memperoleh seluruh repo (meskipun saya menduga itu sebenarnya tidak benar-benar diperlukan untuk git, tetapi dukungan untuk itu terbatas dan itu tidak umum digunakan). Repo build sederhana biasanya hanya cabang overlay tempat Anda menggabungkan / mengekspor pohon build. Beberapa orang menggabungkan sumber daya luar dalam pohon sumber mereka atau memisahkan lebih jauh, eksternal, membangun dan sumber pohon. Biasanya melayani dua tujuan, membangun caching dan membangun berulang, tetapi kadang-kadang membuatnya terpisah pada setidaknya beberapa tingkat juga memungkinkan membangun segar / kosong dan beberapa membangun dengan mudah.

Ada sejumlah strategi untuk ini dan tidak ada satupun dari mereka yang bekerja dengan baik dengan tetap mempertahankan daftar sumber kecuali Anda menyimpan sumber eksternal di pohon sumber Anda.

Mereka juga memiliki hal-hal seperti hash dalam file, bagaimana menggabungkan ketika dua orang memperbarui paket? Itu saja seharusnya membuat Anda berpikir mungkin ini disalahartikan.

Argumen yang diajukan orang untuk file kunci adalah kasus di mana mereka telah mengambil pandangan yang sangat spesifik dan membatasi masalah. Ingin bangunan berulang dan bangunan konsisten? Sertakan folder vendor dalam VCS. Kemudian Anda juga mempercepat pengambilan aset serta tidak harus bergantung pada sumber daya eksternal yang berpotensi rusak selama pembangunan. Tak satu pun dari membangun dan menggunakan pipa yang saya buat memerlukan akses eksternal kecuali benar-benar diperlukan. Jika Anda harus memperbarui sumber daya eksternal itu sekali dan hanya sekali. Apa yang ingin dicapai oleh komposer masuk akal untuk sistem terdistribusi kecuali seperti yang disebutkan sebelumnya tidak masuk akal karena akan berakhir dengan neraka ketergantungan perpustakaan untuk pembaruan perpustakaan dengan bentrokan umum dan pembaruan selambat paket paling lambat untuk memperbarui.

Selain itu saya memperbarui dengan ganas. Setiap kali saya mengembangkan saya memperbarui dan menguji semuanya. Ada jendela yang sangat kecil untuk penyimpangan versi signifikan untuk menyelinap masuk. Realistis juga, ketika versi semantik ditegakkan, yang cenderung untuk komposer, Anda tidak seharusnya memiliki banyak masalah kompatibilitas atau kerusakan.

Di composer.json Anda meletakkan paket yang Anda butuhkan dan versinya. Anda dapat mengunci versi di sana. Namun paket-paket itu juga memiliki dependensi dengan versi dinamis yang tidak akan dikunci oleh composer.json (meskipun saya tidak melihat mengapa Anda tidak bisa juga meletakkannya di sana sendiri jika Anda ingin mereka dikunci versi) sehingga orang lain yang menjalankan komposer menginstal mendapat sesuatu yang berbeda tanpa kunci. Anda mungkin tidak peduli banyak tentang itu atau Anda mungkin peduli, itu tergantung. Haruskah kamu peduli? Mungkin setidaknya sedikit, cukup untuk memastikan Anda menyadarinya dalam situasi apa pun dan dampak potensial, tetapi mungkin tidak menjadi masalah baik jika Anda selalu punya waktu untuk KERING berjalan terlebih dahulu dan memperbaiki apa pun yang diperbarui.

Komposer kerumitan mencoba untuk menghindari kadang-kadang tidak ada dan kerumitan memiliki file kunci komposer dapat membuat signifikan. Mereka sama sekali tidak punya hak untuk memberi tahu pengguna apa yang harus atau tidak boleh mereka lakukan sehubungan dengan aset bangunan versus sumber (apakah akan bergabung terpisah di VCS) karena itu bukan urusan mereka, mereka bukan bos Anda atau saya. "Komposer berkata" bukan otoritas, mereka bukan atasan Anda dan mereka juga tidak memberikan keunggulan kepada siapa pun dalam hal ini. Hanya Anda yang tahu situasi Anda yang sebenarnya dan apa yang terbaik untuk itu. Namun, mereka mungkin menyarankan tindakan default untuk pengguna yang tidak mengerti bagaimana hal-hal bekerja dalam hal mana Anda mungkin ingin mengikuti itu tetapi secara pribadi saya tidak berpikir begitu ' pengganti nyata untuk mengetahui bagaimana hal-hal bekerja dan mampu dengan benar melatih kebutuhan Anda. Pada akhirnya, jawaban mereka untuk pertanyaan itu adalah tebakan terbaik. Orang-orang yang membuat komposer tidak tahu di mana Anda harus menyimpan komposer Anda. Satu-satunya tanggung jawab mereka adalah memberi tahu Anda apa itu dan apa fungsinya. Di luar itu Anda perlu memutuskan apa yang terbaik untuk Anda.

Menyimpan file kunci bermasalah bagi kegunaan karena komposer sangat tertutup tentang apakah menggunakan kunci atau JSON dan tidak selalu baik untuk menggunakan keduanya bersama-sama. Jika Anda menjalankan instal hanya menggunakan file kunci itu akan muncul jadi jika Anda menambahkan sesuatu ke composer.json maka itu tidak akan diinstal karena itu tidak ada dalam kunci Anda. Ini tidak intuitif sama sekali operasi apa yang benar-benar dilakukan dan apa yang mereka lakukan sehubungan dengan file json / kunci dan kadang-kadang tampaknya tidak masuk akal (bantuan mengatakan menginstal mengambil nama paket tetapi pada mencoba menggunakannya itu mengatakan tidak ).

Untuk memperbarui kunci atau pada dasarnya menerapkan perubahan dari json Anda harus menggunakan pembaruan dan Anda mungkin tidak ingin memperbarui semuanya. Kunci diutamakan untuk memilih apa yang harus dipasang. Jika ada file kunci, itu yang digunakan. Anda dapat membatasi pembaruan tetapi sistem masih berantakan.

Pembaruan memakan waktu, pertunjukan RAM. Saya curiga juga jika Anda mengambil sebuah proyek yang tidak tersentuh untuk sementara waktu yang terlihat dari versi yang sudah naik, yang akan ada lebih banyak dari waktu ke waktu dan mungkin tidak melakukan itu secara efisien yang hanya mencekiknya.

Mereka sangat licik ketika datang untuk memiliki perintah komposit rahasia yang Anda tidak bisa harapkan menjadi komposit. Secara default, perintah menghapus komposer muncul di peta untuk memperbarui komposer dan komposer menghapus misalnya.

Pertanyaan yang benar-benar perlu Anda tanyakan adalah bukan apakah Anda harus menyimpan kunci di pohon sumber Anda atau sebagai alternatif apakah Anda harus bertahan di suatu tempat dengan cara tertentu atau tidak, melainkan Anda harus bertanya apa yang sebenarnya dilakukannya, maka Anda dapat memutuskan sendiri ketika Anda perlu bertahan dan di mana.

Saya akan menunjukkan bahwa memiliki kemampuan untuk memiliki kunci adalah kenyamanan ketika Anda memiliki strategi ketekunan ketergantungan eksternal yang kuat karena melacak Anda informasi yang berguna untuk melacak itu (asal) dan memperbaruinya tetapi jika Anda tidak maka tidak ada di sini tidak di sana. Ini tidak berguna ketika dipaksa turun ke tenggorokan Anda sebagai opsi wajib untuk membuatnya mencemari pohon sumber Anda. Ini adalah hal yang sangat umum ditemukan dalam basis kode lama di mana orang telah membuat banyak perubahan pada komposer. Johnny yang belum benar-benar diterapkan dan rusak ketika orang mencoba menggunakan komposer. Tidak ada komposer. Kunci, tidak ada masalah desync.

Ya jelas.

Itu karena komposer yang dipasang secara lokal akan memberikan preferensi pertama pada file composer.lock daripada composer.json.

Jika file kunci tidak tersedia dalam vcs komposer akan menunjuk ke file composer.json untuk menginstal dependensi atau versi terbaru.

File composer.lock mempertahankan ketergantungan secara lebih mendalam, yaitu menunjuk komit aktual dari versi paket yang kami sertakan dalam perangkat lunak kami, karenanya ini adalah salah satu file terpenting yang menangani ketergantungan dengan lebih baik.