Geçişli geliştirme bağımlılıkları için atıf vermeli miyim?
Bağımlılık lisanslarını tek bir dosyada toplamak için bir kütüphane / kli-aracı üzerinde çalışıyorum. Direkt bağımlılıkları, Geçişli-bağımlılıkları ve: Şu anda, ben toplamak lisansların çalışıyorum doğrudan dev bağımlılıklar .
Başka bir deyişle, node_modules'e yüklenmiş paketlerin lisanslarını toplamaya çalışıyorum. Dev-bağımlılıklarının doğası gereği, geçişli geliştirme bağımlılıkları paket yöneticisi tarafından kurulmaz.
Bu geçişli bağımlılıkların kod bölümlerinin bir şekilde kurulu paketlere dahil edilip edilmeyeceğinden endişeleniyorum.
Örneğin: "A" Projesi "B" Paketine bağlıdır. Paket "B", dev-bağımlılık olarak Transpiler "C" ye sahiptir. Paket "B" de Transpiler "C" tarafından üretilen kod, sadece basit bir transpilasyon sonucunu değil, aynı zamanda Transpiler "C" den eski tarayıcılarda bulunmayan bir işlev için bazı çoklu doldurmayı da içerir. Ancak, Transpiler "C" geçişli bir geliştirme bağımlılığı olduğu için, "A" Projesinin node_modüllerine yüklenmez, bu nedenle manuel olarak kurulmadan, Transpiler "C" lisansı düzgün bir şekilde alınamaz, değil mi? Yapabilsek bile, Transpiler "C" bağımlılıklarını / dev-bağımlılıklarını vb. Aramamız gerekecek.
Bu varsayımsal durumda, yalnızca bir geçişli dev-bağımlılığımız var, ancak gerçek dünya senaryolarında yüzlerce olabilir. Farklı paketlerde geçişli dev-bağımlılık olarak tanımlanan aynı paketin birkaç sürümü olabilir. Lisans bilgilerini toplamak için geçişli geliştirme bağımlılıklarını manuel olarak yükleyerek, bu geçişli geliştirme bağımlılıklarının kendi dev bağımlılıkları olabilir ve bunların da yüklenmesi gerekir. Bu işlem, tüm geçişli dev-bağımlılıklarının tüm geçişli dev-bağımlılıkları kurulana kadar tekrarlanmalıdır.
Soru şu: Geçişli geliştirme bağımlılıkları hakkında lisans bilgisi toplamayı önemsemeli miyim? Ve eğer yaparsam, hangi noktaya?
Zaten düzenli geçiş bağımlılıkları ile ilgileniyorum, ancak geçişli geliştirme bağımlılıkları için endişeliyim.
Yanıtlar
Bu gerçekten zor bir senaryodur, bu nedenle otomatik lisans uyumluluk araçları ancak bir yere kadar gidebilir. Analiziniz genellikle doğru görünüyor.
Uygulamada, B'nin lisansının sadece B'nin orijinal kaynak kodunu değil, aynı zamanda B'nin aktarılmış kodunu da (en azından B aktarılmış biçimde dağıtılmışsa) kapsamasını beklerdim. Bu, geçişli dev bağımlılıkları sorunundan düzgün bir şekilde kaçacaktır. Ancak, bu daha genel bir soruna işaret ediyor: lisans meta verileri doğru olmayabilir, bu da otomatikleştirilmiş araçların bu kadar ileri gitmesinin bir başka nedenidir.
Genel amaçlı bir araç tasarlıyorsanız , paket meta verilerinde belirtilen araçlar için meta verileri getirerek dev bağımlılıklarının ve geçişli geliştirme bağımlılıklarının analizini tetikleyen bir seçenek eklemek faydalı olabilir (bunları gerçekten yüklemeye gerek yoktur). Varsayılan olarak, dev bağımlılıklarının lisans durumu üzerinde herhangi bir doğrudan etkisinin olmasını beklememekteyim (ancak, doğru bir şekilde açıkladığınız gibi, özellikle çoklu dolgular bu beklentiyi ihlal edebilir).