Composer.lock sürüm denetimine bağlı olmalı mı?


529

Havuzlu composer.lockbir uygulamada biraz kafam karıştı .

Birçok insanın .gitignore composer.lockdepodan olmamamız gerektiğini söylediğini gördüm .

Kütüphanelerimi geliştirici ortamımda güncellersem, yeni bir tane olacak, composer.lockancak bunları üretime güncelleyemeyeceğim, olur mu?

Bu dosyada çakışma oluşturmayacak mı?


1
Bu bağlantı şimdi öldü @markus
Kyrre

Yanıtlar:


673

Kütüphanelerinizi güncellerseniz, kilit dosyasını da yürütmek istersiniz. Temel olarak projenizin kullandığınız kütüphanelerin belirli sürümlerine kilitli olduğunu belirtir.

Değişikliklerinizi yaparsanız ve birisi kodunuzu alır ve bağımlılıkları güncellerse, kilit dosyasının değiştirilmemesi gerekir. Değiştirilirse, bir şeyin yeni bir sürümüne sahip olduğunuz anlamına gelir.

Depoda olması, her geliştiricinin aynı sürümleri kullandığını garanti eder.


5
Tamam, ama kütüphaneleri üretim ortamından güncellersem düşünün, composer.lock'un üzerine yazılacak, böylece üretimden bir sonraki çekim bu dosyayı birleştirmemi isteyecek ...
Pierre de LESPINAY

7
Composer.lock değiştirilirse, değişiklikleri depoya geri göndermeniz gerekir. Yazılımı kütüphanelerin belirli sürümlerine bağlamak istiyorsanız, bunu yapılandırmada açıkça yapın. Bu şekilde kilit asla değişmez. Kilit dosyasını şu ya da bu şekilde çözülmesi gereken bir bağımlılık yönetimi sorununun göstergesi olarak düşünün.
meza

361
Üretimde bağımlılıklarınızı güncellememelisiniz composer install, kilit dosyasından okuyacak ve hiçbir şeyi değiştirmeyecek şekilde çalıştırmalısınız.
Seldaek

112
"Üretimde bağımlılıklarınızı güncellememelisiniz" tüm harflere yazılmalıdır
Joaquín L. Robles

75
@ JoaquínL.Robles ÜRETİMDE BAĞIMLILIKLARINIZI GÜNCELLEMEMELİSİNİZ! :)
Елин Й.

201

Uygulamalar / projeler için : Kesinlikle evet.

Besteci belgeleri (durularak) bu konuda şöyle der:

Uygulamanızın composer.lock dosyasını (composer.json ile birlikte) sürüm denetimine alın.

@Meza'nın dediği gibi: Kilit dosyasını kaydetmelisiniz, böylece siz ve ortak çalışanlarınız aynı sürümler üzerinde çalışarak "Ama bilgisayarımda çalıştı" gibi sözler söylemenizi önlersiniz. ;-)

Kütüphaneler için : Muhtemelen hayır.

Besteci dokümanları bu konuyla ilgili notları:

Not: Kütüphaneler için kilit dosyasını yürütmeniz önerilmez (...)

Ve burada belirtiyor :

İsterseniz, kitaplığınız için composer.lock dosyasını işleyebilirsiniz. Bu, ekibinizin her zaman aynı bağımlılık sürümlerini test etmesine yardımcı olabilir. Ancak, bu kilit dosyasının ona bağlı diğer projeler üzerinde herhangi bir etkisi olmayacaktır. Sadece ana proje üzerinde bir etkisi vardır.

Kütüphaneler için @Josh Johnson'un cevabına katılıyorum.


Neden işteki projelere "kütüphanelerden" farklı muamele edilmeli?
Josh Johnson

4
Belki de "iş arkadaşları" kelimesinin kullanımı kafa karıştırıcıydı, ben bunu ortak çalışan olarak değiştirdim. Ana fark, bir ana projenin bunları birleştirmek için bir veya daha fazla kütüphane ve koddan oluştuğu "ana proje" ile kütüphane arasındaki farktır. Besteciyi ana projeden çalıştırırken, bir kütüphanenin composer.lock dosyasını kullanmaz, bu nedenle bağımlılıklarını en son sürüme yükler. Kitaplığınızı test ederken bunun da benzer olması gerektiğini düşünüyorum.
Jeroen Fiege

2
Kilit dosyasını bir kitaplıkla yürütmek muhtemelen iyi bir şeydir - test paketi çalıştırıldığında bağımlılık sürümlerinin yüklendiği kilit dosyası belgeleri. Bu özellikle bir ekipte ve özellikle sürekli entegrasyon ortamlarında önemlidir.
mindplay.dk

Her ikisi de besteci aracılığıyla yeni paketler kurulan ana hat 2 dallarına yeniden entegre edilirken önemsiz çatışmalar ortaya çıkabilir. Şu anda oldu :)
g4b0

2
@tonix, buna bir otorite ile cevap verebilirim! Composer.lock'u kütüphanelerim için kullanmamamın nedeni , CI'mın ne olursa olsun her gece ustalık oluşturmasıdır. Kütüphanenin bağımlılıklarından herhangi birinin yükseltme problemleri varsa, kütüphane kullanıcısının CI'nin başarısız olacağını garanti eder. İyi çalışıyor!
Theodore R. Smith

86

Birkaç proje için her iki şekilde yaptıktan sonra, benim görüşüm composer.lock, projenin bir parçası olarak işlenmemelidir.

composer.lockprojenin bir parçası olmayan meta veriler oluşturmaktır. Bağımlılıkların durumu, bunları nasıl güncellediğiniz ve kilit dosyasını yürütmek için keyfi olarak son geliştirici tarafından değil, sürümleri (el ile veya otomatik oluşturma işleminizin bir parçası olarak) nasıl kontrol ettiğinizle kontrol edilmelidir.

Bestecinin güncellemeleri arasında değişen bağımlılıklarınızla ilgili endişeleriniz varsa, versiyonlama şemanıza güveniniz yoktur. Sürümler (1.0, 1.1, 1.2 vb.) Değişmez olmalı ve ilk özellik geliştirmenin dışında "dev-" ve "X. *" joker karakterlerinden kaçınmalısınız.

Bağımlılık sürümü artık dolaylı olarak tanımlanmaya geri döndüğünden, kilit dosyasının işlenmesi bağımlılık yönetim sisteminiz için bir gerilemedir.

Ayrıca, projeniz asla yeniden inşa edilmemeli veya bağımlılıkları her ortamda, özellikle de ürünlerinde yeniden kullanılmamalıdır. Teslimatınız (katran, zip, phar, bir dizin vb.) Değişmez olmalı ve değişmeden ortamlar aracılığıyla tanıtılmalıdır.


19
Kabul. composer.jsonGerekli sürümlerin daha açık bir şekilde belirtildiği bağımlılık sürümlerini belirtmenin daha anlamlı olduğunu düşünüyorum. Eğer Ama eğer yok özel sürümler ayarlamak, daha iyi işlemeye composer.lock. Belirtilen sürümlerin composer.json, a'ya göre yüklü sürümlerden farklı olması kafa karıştırıcıdır composer.lock. Ayrıca uygulamaya (şirket içi veya genel sürüm) ve geliştirici döngüsüne bağlıdır. Elbette, besteci dokümanları kalın harflerle "Uygulamanızın composer.lock dosyasını (composer.json ile birlikte) sürüm kontrolüne ekleyin" der . Akıllıca seçin =)
Quinn Comendant

10
Çok ruh arama sonra karar verdim, bu noktada, besteci dokümanlar yanlış :) Ben VCS oluşturulan malzeme eklemek bir kural var; İnşa sürecinin bunun üstesinden gelmesine izin veriyorum.
Josh Johnson

10
Kod, biyomekanik tuş baskı makineleriniz "oluşturulan malzeme" kullanılarak oluşturulmuyor mu? Bunun bir politikayı dayandırmak için sağlam bir kriter olduğundan emin değilim. =)
Quinn Komutanı

5
@borfast Konuşmaya biraz geç kaldığımı biliyorum, bu yüzden bu noktaya kadar görmüş olabilirsiniz ama, içinde bir karma belirtebilirsiniz composer.json. In requirebölümünde, koyabilirsiniz: "repo": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e". Bu 1) şubeye gidecek, 2) karma olan ödeme, 3) karma şubede bulunmazsa, belirtilen şubenin başını kontrol edecektir (bu durumda master).
CEPA

5
@CEPA - Bu çok garip. Karma bulunamazsa başarısız olmasını beklerdim. Tehlikeli görünüyor.
Nathan JB

31
  1. Bağımlılıklarınızı doğrudan Üretim'e güncellememelisiniz.
  2. Composer.lock dosyanızı sürüm kontrolü yapmalısınız .
  3. Gerçek bağımlılıklarınızı kontrol etmemelisiniz.

1. Bağımlılıklarınızı doğrudan Üretim'e güncellememelisiniz , çünkü bunun kodunuzun kararlılığını nasıl etkileyeceğini bilmiyorsunuz. Yeni bağımlılıklarla karşılaşılan hatalar olabilir, kodun kendi davranışınızı etkileme biçimini değiştirebilir, diğer bağımlılıklarla vb. Uyumlu olmayabilir. .

2. Composer.lock dosyanızı sürüm denetimi yapmalısınız , çünkü bu sizin bağımlılıklarınız ve kodunuzun geçerli durumunu çoğaltmanıza izin verecek olan bağımlılıklarınızın bağımlılıkları hakkında bilgi depolar. Bu önemlidir, çünkü tüm test ve geliştirmeleriniz belirli kodlara göre yapılmıştır. Kodun sahip olduğunuz gerçek sürümüne dikkat etmemek, kod değişikliklerini uygulamanıza yüklemeye ve test etmemeye benzer. Bağımlılık sürümlerinizi yükseltiyorsanız, bu isteyerek hareket etmeli ve her şeyin hala çalıştığından emin olmak için gerekli özeni göstermelisiniz. Önceki bir sürüme geri dönmek için bir veya iki saatlik çalışma süresini kaybetmek size çok pahalıya mal olabilir.

Composer.lock'a ihtiyaç duymamanızla ilgili göreceğiniz argümanlardan biri, composer.json dosyanızda tam olarak ihtiyacınız olan sürümü ayarlayabilmenizdir ve bu şekilde, birisi her çalıştığında composer installbunları aynı şekilde yükleyecektir. kodu. Bu doğru değildir, çünkü bağımlılıklarınızın kendi bağımlılıkları vardır ve yapılandırmaları alt sürümlere veya hatta tüm sürümlere güncellemelere izin verecek bir biçimde belirtilebilir.

Bu, composer.json'unuzda Laravel 4.1.31'i istediğinizi belirttiğinizde bile , composer.json dosyasındaki Laravel'in Symfony event-dispatcher: 2. * gibi kendi bağımlılıklarına sahip olabileceği anlamına gelir . Bu tür bir yapılandırma ile, Syvelfon olay dağıtıcı 2.4.1 ile Laravel 4.1.31 ile sonuçlanabilir ve ekibinizdeki başka biri olay dağıtıcı 2.6.5 ile Laravel 4.1.31'e sahip olabilir, hepsi ne zaman besteci yüklemesini en son çalıştırdığınız zamandı.

Bu nedenle, composer.lock dosyanızın sürüm sisteminde olması bu alt bağımlılıkların tam sürümünü depolar, bu nedenle siz ve ekip arkadaşınız bir besteci yüklemesi yaptığınızda (bu, bağımlılarınızı bir besteciye göre kurmanın yoludur . kilitli ) ikiniz de aynı sürümleri alacaksınız.

Güncellemek istersen? Sonra dev ortamınızda çalıştırın:, composer updatebu yeni bir composer.lock dosyası (yeni bir şey varsa) ve test ettikten sonra üretecek ve KG testi ve regresyon testi ve benzeri şeyler oluşturacaktır. Yeni composer.lock'u indirmek için herkesin bunu zorlayabilirsiniz , çünkü yükseltme güvenli.

3. Gerçek bağımlılıklarınızı kontrol etmemelisiniz , çünkü mantıklı değildir. Composer.lock ile bağımlılıkların tam sürümünü yükleyebilirsiniz ve bunları taahhüt etmeniz gerekmez. Güncellemeniz gerekmediğinde neden repo 10000 bağımlılık dosyalarınıza ekleyesiniz? Bunlardan birini değiştirmeniz gerekiyorsa, çatallanmalı ve değişikliklerinizi orada yapmalısınız. Ayrıca, bir derleme veya sürümün her seferinde gerçek bağımlılıkları almak zorunda olduğunuzdan endişe ediyorsanız, bestecinin bu sorunu, önbelleği, zip dosyalarını vb.


1
Teşekkürler, bence bu cevap neden composer.lock sürümünü kullanmanız gerektiğini açıklıyor ve eğer değilse, sonuçların ne olduğunu ve onlarla birlikte yaşayabiliyorsanız.
José Lozano Hernandez

8

Daha sonra composer.jsonprojenizi taahhüt edersiniz ve ekibinizdeki herkes proje bağımlılıklarınızı yüklemek için besteci yüklemesini çalıştırabilir.

Kilit dosyasının amacı, yeniden yüklenebilmeleri için yüklenen sürümlerin tam olarak kaydedilmesidir. Bu, sürüm 1 spesifikasyonunuz varsa ve iş arkadaşınız 1.2.4'ü yükleyen ve ardından composer.lock dosyasını işleyen besteci güncellemesini çalıştırırsa, besteci yüklediğinizde bile 1.2.4, 1.3.0 yayınlandıysa. Bu, proje üzerinde çalışan herkesin tam olarak aynı sürüme sahip olmasını sağlar.

Bu, bir besteci yüklemesinin son yapılmasından bu yana bir şey yapıldıysa, bir kilit dosyası olmadan, yeni üçüncü taraf kodunun kaldırılacağı anlamına gelir .

Yine, kod kırma konusunda endişeleriniz varsa bu bir sorundur. Ve Composer'ın composer.lock dosyası etrafında merkezlenmiş olarak düşünülmesinin önemli nedenlerinden biri de budur.

Kaynak: Besteci: Herşey Kilit Dosyası Hakkında .


Uygulamanızın composer.lock dosyasını (composer.json ile birlikte) sürüm denetimine alın. Bu, install komutunun bir kilit dosyasının mevcut olup olmadığını kontrol etmesi ve varsa, orada belirtilen sürümleri indirmesi (composer.json'un ne söylediğine bakılmaksızın) nedeniyle önemlidir. Bu, projeyi kuran herkesin bağımlılıkların tam sürümünü indireceği anlamına gelir. CI sunucunuz, üretim makineleriniz, ekibinizdeki diğer geliştiriciler, her şey ve herkes aynı bağımlılıklarla çalışır ve bu da dağıtımların yalnızca bazı bölümlerini etkileyen hata olasılığını azaltır. Yalnız gelişseniz bile, projeyi yeniden yüklerken altı ay içinde, bağımlılıklarınız o zamandan beri birçok yeni sürüm yayınlasa bile, yüklenen bağımlılıkların hala çalıştığından emin olabilirsiniz.

Kaynak: Besteci - Temel Kullanım .


1

Kod kırma konusunda endişeleriniz varsa, composer.locktüm proje ortak çalışanlarınızın kodun aynı sürümünü kullandığından emin olmak için sürüm kontrol sisteminize bağlı kalmalısınız . Bir kilit dosyası olmadan, her seferinde yeni üçüncü taraf kodu alınıyor.

Bunun istisnası, meta uygulamaları, yükleme sırasında bağımlılıkların güncellenmesi gereken kütüphaneleri ( Zend Framework 2 Skeleton App gibi ) kullanmanızdır. Dolayısıyla amaç, gelişmeye başlamak istediğiniz her seferinde en son bağımlılıkları elde etmektir.

Kaynak: Besteci: Her Şey Kilit Dosyası Hakkında

Ayrıca bkz: Besteci güncelleştirmesi ile besteci yüklemesi arasındaki farklar nelerdir?


1

Buna kesin bir cevap yok.

Genel olarak, besteci derleme sisteminin yapması gereken şeyi yapmamalı ve composer.lock'u VCS'ye koymamalısınız. Besteci tuhaf bir şekilde geri alabilir. Üretimler yerine son kullanıcılar kilit dosyalarını kullanmamalıdır. Genellikle derleme sisteminiz her seferinde boş bir dizin yerine anlık görüntüleri, yeniden kullanılabilir dizinleri vb. Tutar. İnsanlar besteciden bir lib'e ödeme yaparlar, lib'in yüklerinin bağımlılıklarının test edilmesi için bir lib kullanmasını isteyebilirler.

Öte yandan, bağımlılık kesinlikle kilitleneceğinden, her kitaplığın birden çok sürümünü kesinlikle kesinlikle isteyeceğiniz sürüm yönetimi yükünü önemli ölçüde artırır. Her kütüphanenin biraz farklı bir sürümü olması muhtemelse, birden fazla kütüphane sürümü desteğine ihtiyacınız vardır ve ayrıca gereken bağımlılıkların boyutunu hızlıca görebilirsiniz, bu nedenle onu yaprak üzerinde tutmanızı öneririz.

Bunu aldığımda, kilit dosyalarını kütüphaneler veya kendi iş dizinleriniz için yararlı bulamıyorum. Sadece benim için kullanıyorum, harici olarak edinilen varlıkların sadece talep edildiğinde güncellenmesi ve test edilmesi, derlenmesi ve dağıtılması için tekrarlanabilir yapılar sağlayan kalıcı / test platformumda. Bu VCS'de tutulabilirken, her zaman kaynak ağacı ile tutulmazken, yapı ağaçları VCS yapısının başka bir yerinde olacak veya başka bir sistem tarafından yönetilecektir. Bir VCS'de depolanırsa, kaynak ağaçlarla aynı repoda tutulup tutulmayacağı tartışmalıdır, aksi takdirde her çekme bir yığın yapı varlığı getirebilir. Üretim / hassas kimlik bilgileri ve şişkinlik haricinde her şeyin iyi düzenlenmiş bir repoda olmasını seviyorum.

SVN, tüm repoyu elde etmenizi zorlamadığı için git'ten daha iyi yapabilir (gerçi bunun git için kesinlikle gerekli olmadığından şüpheleniyorum, ancak bunun desteği sınırlı ve yaygın olarak kullanılmıyor). Basit yapı depoları genellikle yapı ağacını birleştirdiğiniz / dışa aktardığınız bir kaplama dalıdır. Bazı insanlar dış kaynakları kaynak ağaçlarında birleştirir veya dış, dış yapı ve kaynak ağaçlarını ayırır. Genellikle iki amaca hizmet eder, önbellekleme ve tekrarlanabilir yapılar oluşturur, ancak bazen en azından bir düzeyde ayrı tutmak, taze / boş yapılara ve çoklu yapılara kolayca izin verir.

Bunun için bir takım stratejiler vardır ve dış kaynağı kaynak ağacınızda tutmamanız durumunda hiçbiri özellikle kaynaklar listesine devam etmede işe yaramaz.

Ayrıca dosyada karma gibi şeyler var, iki kişi paketleri güncellediğinde bu nasıl birleşir? Sadece bu seni yanlış düşünebilir.

İnsanların kilit dosyaları için öne sürdüğü argümanlar, sorunun çok spesifik ve kısıtlayıcı bir görünümünü aldıkları durumlardır. Tekrarlanabilir derlemeler ve tutarlı derlemeler ister misiniz? VCS'ye satıcı klasörünü ekleyin. Daha sonra aynı zamanda varlıkları getirmeyi de hızlandırırsınız ve derleme sırasında potansiyel olarak bozuk dış kaynaklara bağımlı olmanız gerekmez. Oluşturduğum ve dağıttığım boru hatlarının hiçbiri, kesinlikle gerekli olmadıkça harici erişim gerektirmez. Harici bir kaynağı güncellemeniz gerekiyorsa, bu kaynağı bir kez ve yalnızca bir kez. Bestecinin elde etmeye çalıştığı şey, mantıklı gelmediği sürece, dağıtılmış bir sistem için mantıklıdır, çünkü yaygın çatışmalar ve güncellemelerin en yavaş güncellenen paket kadar yavaş olduğu kütüphane güncellemeleri için kütüphane bağımlılığı cehennemi ile sonuçlanacaktır.

Ek olarak acımasızca güncelliyorum. Her geliştirdiğimde her şeyi güncelliyor ve test ediyorum. Önemli sürüm sürüklenmesinin gizlice girmesi için çok küçük bir pencere var. Gerçekçi olarak, semantik sürümleme desteklendiğinde, besteci olma eğilimindedir, pek çok uyumluluk sorunu veya kırılması olduğunu düşünmüyorsunuz.

Composer.json içinde istediğiniz paketleri ve sürümlerini koyabilirsiniz. Sürümleri orada kilitleyebilirsiniz. Ancak bu paketler ayrıca composer.json tarafından kilitlenmeyecek dinamik sürümlerle bağımlılıklara sahiptir (ancak, sürüm kilitli olmasını istiyorsanız neden bunları kendiniz de koyamazsınız). kilit olmadan farklı bir şey alır. Bu konuda çok fazla umursamazsınız veya umursabilirsiniz, duruma göre değişir. Umursar mısın? Muhtemelen en azından biraz, herhangi bir durumda ve potansiyel etkiden haberdar olmanız için yeterli, ancak her zaman sadece KURU çalıştırma ve güncellenen herhangi bir şeyi düzeltmek için zamanınız varsa sorun olmayabilir.

Güçlük bestecisi bazen sadece orada değil kaçınmaya çalışıyor ve besteci kilit dosyaları yapabilirsiniz güçlük önemli. Kullanıcılara, kaynak varlıklara karşı (VCS'de ayrı ayrı katılma) karşı ne yapmaları veya yapmamaları gerektiğini söyleme hakları yoktur, çünkü bu onların işlerinden hiçbiri değildir, onlar sizin veya benim patronumuz değildir. "Besteci diyor ki" bir otorite değil, onlar sizin üst düzey subay değilsiniz ve bu konuda kimseye üstünlük de vermiyorlar. Gerçek durumunuzu ve bunun için en iyi olanı yalnızca siz bilirsiniz. Ancak, işlerin nasıl çalıştığını anlamayan kullanıcılar için varsayılan bir işlem önerebilirler, bu durumda bunu takip etmek isteyebilirsiniz, ancak şahsen şunu düşünmüyorum ' İşlerin nasıl çalıştığını bilmek ve ihtiyaçlarınızı doğru bir şekilde çalıştırabilmek için gerçek bir yedek. Sonuçta, bu soruya verdikleri cevap en iyi tahmindir. Besteci yapan kişiler bestecinizi nerede tutmanız gerektiğini bilmezler. Tek sorumluluğu size ne olduğunu ve ne yaptığını söylemektir. Bunun dışında sizin için neyin en iyi olduğuna karar vermelisiniz.

Kilit dosyasını saklamak kullanılabilirlik açısından sorunludur çünkü besteci kilit veya JSON kullanıp kullanmadığı konusunda çok gizlidir ve her ikisini birden birlikte kullanamaz. Eğer install çalıştırırsanız sadece kilit dosyasını kullanır, bu yüzden composer.json'a bir şey eklerseniz, kilidinizde olmadığı için yüklenmeyecektir. İşlemlerin gerçekte ne yaptığı ve json / lock dosyasıyla ilgili olarak yaptıkları şeylerin sezgisel olmadığı ve bazen mantıklı görünmediği (yardımın kurulumun bir paket adı aldığını söylüyor ancak kullanmaya çalıştığında hayır diyor ).

Kilidi güncellemek veya temelde json'daki değişiklikleri uygulamak için güncellemeyi kullanmanız gerekir ve her şeyi güncellemek istemeyebilirsiniz. Kilit, neyin kurulması gerektiğini seçmek için önceliklidir. Bir kilit dosyası varsa, kullanılan budur. Güncellemeyi biraz kısıtlayabilirsiniz, ancak sistem hala sadece bir karışıklıktır.

Güncelleme bir yaş alır, RAM konserleri. Bir süredir dokunulmamış bir projeyi seçtiği sürümlerden baktığından şüpheliyim, ki bu da zamanla daha fazla olacak ve muhtemelen bunu boğucu hale getiren verimli bir şekilde yapmıyor.

Kompozit olmasını bekleyemeyeceğiniz gizli kompozit komutlar söz konusu olduğunda çok sinsidirler. Varsayılan olarak besteci kaldırma komutu, örneğin besteci güncellemesiyle eşleşir ve besteci kaldırır.

Gerçekten sormanız gereken soru, kilidi kaynak ağacınızda tutmanız gerekip gerekmediği veya alternatif olarak onu bir şekilde devam ettirmeniz gerekip gerekmediği değil, aslında ne yaptığını sormanız gerektiğidir, o zaman kendiniz karar verebilirsiniz. ne zaman ve nerede ısrar etmeniz gerektiğinde.

Sağlam bir bağımlılık kalıcılık stratejisine sahip olduğunuzda, kilide sahip olma yeteneğine sahip olmanın büyük bir kolaylık olduğuna dikkat çekeceğim, çünkü sizi (kökenleri) izlemek ve güncellemek için yararlı bilgileri takip eder, ancak o zaman burada da değil. Kaynak ağaçlarınızı kirletmesi için zorunlu bir seçenek olarak boğazınızdan aşağıya zorlandığında yararlı değildir. İnsanların composer.json üzerinde gerçekten uygulanmayan ve insanlar besteci kullanmaya çalıştıklarında kırılan eski kod tabanlarında bulmak çok yaygın bir şeydir. Composer.lock yok, desync sorunu yok.


0

Evet tabii ki.

Bunun nedeni, yerel olarak yüklenmiş bir bestecinin composer.lock dosyasına composer.json yerine ilk tercihi vermesidir.

Kilit dosyası vcs dosyasında mevcut değilse, besteci en son bağımlılıkları veya sürümleri yüklemek için composer.json dosyasını gösterecektir.

Composer.lock dosyası, bağımlılığı daha derinlemesine korur; yani, yazılımımıza dahil ettiğimiz paket sürümünün gerçek taahhüdüne işaret eder, bu nedenle bu, bağımlılığı daha ince işleyen en önemli dosyalardan biridir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.