g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Monorepo sandığınız kadar güzel kokulu olmayabilir ...

Tam metin 2500 kelime ve beklenen öğrenme süresi 10 dakikadır

Resim kaynağı: slayt paylaşımı

Son zamanlarda, pek çok popüler açık kaynak projesinde, React, Parcel, Babel, vb. Gibi bir depoda birden fazla npm mikro paketi içeren böyle bir fenomen var.

Ancak Monorepo sandığınız kadar güzel kokulu olmayabilir.Yazar, çoğu durumda bu modelin projeye yarardan çok zarar verdiğine inanıyor.Gereksiz karmaşıklık getiriyor ve yazarların ve geliştiricilerin kullanılabilirliğini feda ediyor.

Neden Monorepos'u seçmelisiniz?

Monorepos kavramı, bağımlılık yönetimini basitleştirmektir. Proje, birbirinin belirli sürümlerine bağlı olması gereken birçok paket içeriyorsa, bunları ayrı bir depo yerine tek bir yere koyarak yönetmek daha kolaydır.

Benzer şekilde, tarihsel bir kayıt için, bu paketlerin her zaman eşzamanlı veya "atomik" taahhütleri olacaktır. İşleri kolaylaştırmak için, tüm paketlerin yayınını otomatik olarak yönetmek için özel bir komut dosyası kullanabilirsiniz, böylece paket karşılık gelen bir paket olmadan yayınlanmayacaktır.

Bir JavaScriptmonorepo projesi genellikle şu yapıya sahiptir:

myproject.git / paketleri / paket-1 / package.json paket-2 / package.json paket-3 / package.json ... Kodlar/ common-publishing-script.js

Bu sadece küçük bir örnek, monoreposların ne kadar büyüyebileceğini görebilirsiniz:

· Tepki: 32 paket

(Https://github.com/facebook/react/tree/master/packages)

· Koli: 81 torba

(Https://github.com/parcel-bundler/parcel/tree/v2/packages)

· Babel: 138 paket

(Https://github.com/babel/babel/tree/master/packages)

Bu çok saçma ve monorepos kavramına neden karşı çıkmamız gerektiğini ve bunun neden bir anti-model olduğunu açıklayacağım.

Monolitleri örtün

Kodu birden çok pakete ayırmanın çeşitli faydaları vardır.Bir kitaplık, mikro hizmet veya mikro ön uç olsun, derleme hızı önemli ölçüde iyileştirilir, bağımsız dağıtım ve birden çok ekip arasında paralel geliştirme, tümü geçilir Entegrasyon için herkesin güvenebileceği bir kural API'si.

Ancak, bunların tümü aynı depoda barındırılırsa, pek çok fayda artık mevcut olmayacaktır.

Kaynak: unsplash

Monorepos'un ilk başta monolith ile aynı problemlere sahip olmadığı ve paketi ayrı ayrı tutabildiği görülse de, bu depoları daha fazla kontrol ederken monolit çok açık hale geliyor. Genellikle, tüm paketlerin çalışması için birbirine bağlı olma eğiliminde olduğu karmaşık bir bağımlılık ağacı vardır.

Paketlerden birinde bir değişiklik yapılırsa, bu paketi kullanan paketler üzerinde dalgalanma etkisi yaratabilir ve bu paketlerin kendileri güncellenmeli ve serbest bırakılmalıdır. Genellikle monorepozda, paketin işlevi çok özeldir, o zaman soru, sıkıca bağlanmışsa, neden ayrı bir paket var? Bu paketler bağımsız olarak kullanılabilir mi? Veya monorepo'daki diğer paketlerin belirli sürümlerine bağlanmak mı? Kamuflajı çıkarmak tıpkı momolith gibi daha kolay olabilir.

Yalnızca bir paket, kendisi olan Parcel paketini kullanır.

Paket ek yükü

Nispeten basit bir uygulama için bile node_modules dizinine bakıldığında yüzlerce hatta binlerce paket olabilir. Genellikle böyle bir paket yalnızca birkaç satır kod içerir ve LICENSE, README ve package.json dosyaları ile birlikte gelir.

Bu inanılmaz bir masraf ve israftır. Paketler daha fazla sabit disk alanı tüketir, yükleme süresini artırır ve işlev açısından daha belirsiz hale gelir, böylece bazı adlar işlevlerini doğrudan açıklar.

Düğüm projelerinde çok yaygın bağımlılıklar. Bu türden daha az pakete ihtiyacınız var.

Monorepos bu sorunu büyütür. Genellikle gereksiz yere işlevselliği tek bir pakete ayırırlar. Bir paketin tek gerçek kullanıcısı monorepo ise ve bu depodaki diğer 138 paket arasına sıradan bir kullanıcının bu paketi yüklediğini göremezseniz, onu ayrı bir paket olarak ele almanız gerekmeyebilir. İdeal olarak, kullanıcıların her şeyi içeren ve ek yükü azaltan bir paket yüklemelerine izin vermek en iyisidir.

Geliştirici kafa karışıklığı

Birçok monorepos, paketleri npm olarak yayınlar, bu da bazı sorunlara neden olabilir. İlk sorun, geliştiricilerin bu paketlerden bazılarını yüklemesini istiyorsanız, sürüm numaralarının karıştırılabileceğidir. Paket sıkıca bağlanmışsa, paketi birlikte nasıl kullanacağınızı bulmak sinir bozucu olabilir.

Bazı monorepos, sürüm numaralarını senkronize tutarak bu sorunu çözer, ancak bunu yapıyorlarsa, neden ayrı bir paket oluşturmaya değer olduğu sorusunu tekrar gündeme getirir.

Belgelere sahip olmayan genel bir Babel paketi.

Diğer bir sorun, ayrı bir paket yayınlamanın özel işlevleri açığa çıkarmasıdır. Kullanıcıların belgelenmemiş özellikleri kullanmamaları beklenmesine rağmen, erişmenin bir yolu varsa kullanıcılar bunu kullanacaktır. Bu, geliştiricileri belirli uygulama ayrıntılarında geriye dönük uyumluluğu sürdürmeye zorlar.

Bir yazılım paketini çok değiştirmek istiyorsanız, yalnızca bazı kişiler açıklanmayan API'de bulunan pakete güvenebileceği için ana sürüm numarasını artırmanız gerekebilir.

Kaynak: unsplash

Git geçmişini izle

Git deposundaki geçmiş kayıtlar, özellikle paketin zaman içinde nasıl değiştiğini ve yapılan bazı değişiklikleri geri almanız gerekip gerekmediğini anlamanız gerekiyorsa çok önemli olabilir. Bazı insanlar monoreposun avantajlarından birinin, tüm paketlerin aynı uyumluluğa sahip olacak şekilde aynı anda geri yüklenebilmesi olduğunu düşünüyor.

Bu iyi bir noktadır, ancak sürüm kontrolünün yalnızca bir yönünü diğerlerinin zararına olacak şekilde basitleştirir.

Yazar için çoğu durumda tek bir paketi geri yüklemek veya pakette yapılan değişiklikleri kontrol etmek istiyorum. Monorepo bağlamında, bu daha zor hale gelebilir. Aramaya filtre uygulamaya başlamalısınız, ancak monorepo'daki paketlerin sıkı bir şekilde bağlı olduğunu göz önünde bulundurarak, yine de yüzlerce alakasız paket içinde diğer ilgili paketlerde yapılan değişikliklere bakmanız gerekir.

Kaynak: unsplash

Git'in monorepo düzeyinde çalışmak üzere tasarlanmadığını belirtmekte fayda var. Depoda ne kadar çok dosya ve işlem yapılırsa, Git ile herhangi bir temel komutu yürütmek o kadar yavaş olur. Atlassian, bu konu hakkında bazı teknik detaylar verdi.

ESM modülü şimdi

Monorepos'un var olmasının ve daha önce çoklu mikro paketlere sahip olmasının nedenlerinden biri, bağlanmayı iyileştirmek ve kullanılmayan fonksiyonların uygulamaya bağlı kalmamasını sağlamaktı.

Lodash gibi kütüphaneler bu modeli iyi bir şekilde destekler. Yalnızca küçük bir Lodash kodu kullanmak istiyorsanız, geri kalan Lodash kodunu hariç tutmak için paketi ayrı ayrı içe aktarabilirsiniz.

Ancak, paketlerde ağaç sallama yaygınlaştıkça, kullanımdan kaldırılmaya başlandı. ESM artık NodeJS dahil her yerde desteklendiğinden, paket boyutunu küçültmek için ayrı bir paket kullanmak için hiçbir neden yoktur.

Özel iç içe paket

Yine de, havuzda ayrı bir paket kullanmayı düşünmek için hala nedenler vardır. Geliştiricilerin, bu paketleri herhangi bir yerde yayınlamalarına gerek kalmadan içe aktarma ve birleştirme sürecini basitleştirmelerine yardımcı olabilir. PreactCompat buna iyi bir örnektir.

Kullanıcıların içe aktarabileceği isteğe bağlı dosyalar varsa, ancak kullanıcıların belirli JavaScript dosyalarına başvurmak zorunda kalmasını istemiyorsanız ve paketleyicinin ortam için doğru biçimi otomatik olarak seçmesini istiyorsanız, ayrı bir package.json kullanın.

Yukarıdaki örnekte, paketleyici doğrudan dosyaya işaret etmek yerine basitleştirilmiş bir yol kullanabilir.Ayrıca, paket meta verilerine dayalı olarak dosyanın UMD veya ESM sürümünü kullanıp kullanmayacağına da karar verebilir.

sonuç olarak

Monorepos'un aşırı mühendislik çalışması ve çok fazla özelliği paketlere ayırması gibi, kodu çok fazla depoya bölmek de öyle. Bir model diğerinden daha anlamlı olduğunda tartışılacak başka ne var?

Bir maliyet-fayda analizi gereklidir ve özellik, içe aktarılabilen ayrı bir dosya olarak veya tamamen ayrı bir havuza değil, ayrı bir paket olarak bir havuza yerleştirilir. Bunun avantajı, ne? Her zaman bakım masraflarını dikkate almanız mı gerekiyor?

Kaynak: unsplash

Kişisel olarak, yukarıda sıralanan tüm nedenlerden dolayı, monprepos ileriye giden yol değildir, aksine kaçınılmalıdır. Ayrıca "çukur" dan kaçınmanıza yardımcı olmayı umuyorum.