Herkese merhaba! Eminim farklı paket yöneticileri kullanan görmüşsünüzdür, örneğin: Node.js projelerini (varsayılan) npm iplik ppmpm Bunu kendim gördüm ve yukarıdakilerin hepsiyle çalıştım, ancak aklımda her zaman bir soru vardı: İnsanları/ekipleri yerine veya kullanmaya iten şey nedir? Artıları nelerdir? Eksileri var mı? npm iplik pnpm Peki… Haydi öğrenelim! Performans Karşılaştırma Kuralları , ve “hızları” açısından karşılaştırmaya karar verdim… Npm iplik pnpm'yi Aşağıda 3 önlem göreceksiniz: Önbellek olmadan bir kilit dosyası oluşturun. Mevcut kilit dosyalarından bağımlılıkları önbellek olmadan yükleyin. Bağımlılıkları genel önbellek ile mevcut kilit dosyalarından yükleyin. İki tür önbellek vardır: Küresel. Genellikle kullanıcının ana dizininde saklanır (fe, ). ~/.yarn/berry/cache Yerel. Proje dizininde saklanır (fe, ). <project-dir>/.yarn Deneyimlerime göre ve en yaygın kullanım durumları olsa da, her ihtimale karşı de aldım (gerçi bu çok nadir bir durum). # 2 # 3 # 1'i Karşılaştırmalar için örnek olarak örnek bir proje kullandım. create-react-app'ten npm ekosistemi için varsayılan bir paket yöneticisidir; başka ne söylenebilir ki? Kurulum paketiyle birlikte gelir, yani makinenize (veya orada kurduysanız herhangi bir sağlayıcısına) yüklediğinizde temel olarak kullanıma hazır olur. Node.js Node.js'yi Node.js'yi CI Bu bence çok büyük bir "profesyonel"; ayrıca yüklemenize gerek yok! Orada olağanüstü bir şey yok - sadece… işe yarıyor! Ve yıllar boyunca herhangi bir büyük hata görmedim; oldukça kararlı görünüyor ve işi hallediyor. Şu ana kadar kullandığım özellikleri: npm'nin Bağımlılıkları yönetin (kurun, kaldırın, güncelleyin) Paketleri yayınlama (özel, genel) Yerel paketlere bağlantı Çalışma alanlarını yönetin. Bağımlılıkları Yönet bağımlılıkları proje kökünüzün klasöründe saklar. Oldukça basit. npm, node_modules ℹ️ listelenen paketler için kayıt defterleri hakkındaki bilgileri saklar - tek bir kapsamdan paketleriniz varsa, yani farklı kayıtlardaki paketleriniz varsa kullanışlı olur (örneğin - ve ): package-lock.json @example-company ÇOK npm GitHub Paketleri Şimdi gelin kurulum hızı açısından nasıl performans gösterdiğine bakalım… Herhangi bir Önbellek Olmadan package-lock.json Oluştur Aldı bir oluşturması ve bağımlılıkları önbellek olmadan kurması için. 1 dakika npm'nin package-lock.json Kullanılan komut: npm i Bağımlılıkları package-lock.json'dan Önbellek Olmadan Yükleyin Aldı herhangi bir önbellek olmadan bağımlılıkları yüklemesi için. 18 saniye npm'nin package-lock.json Kullanılan komut: npm ci Bağımlılıkları package-lock.json'dan Global Önbellek ile Kurun Aldı global önbellek ile bağımlılıkları yüklemesi için. 8 saniye npm'nin package-lock.json Kullanılan komut: npm ci Çalışma Alanlarını Yönet oluşturup tüm çalışma alanı için aynı anda ve belirli projeler için bağımlılıkları ayrı ayrı yönetebildim. Bir çalışma alanı Başka bir deyişle, işi herhangi bir hata/sorun olmadan halleder ve resmi belgeler oldukça basittir. Şu ana kadar kullandığım çalışma alanı özellikleri: Çalışma alanındaki tüm projeler için bağımlılıkları yükleyin. Tek bir spesifik proje için bağımlılıkları yükleyin. Tüm projeler için tek bir komut dosyasını aynı anda yinelemeli olarak çalıştırın. iplik Açıkçası bazı özelliklerini pek denemedim. Yani bazı projeler üzerinde çalışırken “bağımlılık kurma” anlamında bunu çok kullandım, o kadar. iplik bir yükleyicisiyle birlikte gelmez, dolayısıyla onu ayrı olarak yüklemeniz gerekir. Bu, işlem hatlarınızda ek bir adım olacağı anlamına gelir; proje bağımlılıklarınızı kurmadan önce ayarlamanız gerekir. iplik Node.js CI ipliği Bağımlılıkları Yönet bağımlılıkları kurmak için iki yaklaşıma sahiptir: iplik “ ” (varsayılan) - klasörü oluşturur ve ve dosyalarındaki paketleri listeler. Sıfır Kurulum .yarn yarn.lock .pnp.cjs Normal bir tane - benzer, bağımlılıkları saklar ve bunları dosyasında listeler. npm'ye node_modules yarn.lock ℹ️ kilit dosyaları, eski (normal) kurulum yaklaşımını kullanıyorsanız listelenen tüm paketler için kayıtlarla ilgili bilgileri saklar. iplik YALNIZCA ⚠️ " " paketleri yerel önbellekte depoladığını ve kilit dosyalarınıza bağlantılar sağladığını unutmayın: Sıfır Kurulumun Bağımlılıkları temiz bir ortama yüklediğiniz ve ardından bunu başka bir ortama taşımak istediğiniz bir veya işlem hattınız varsa, bu sizin için önemli olabilir (hem klasörünü hem de yerel önbelleği kopyalamanız gerekir). Dockerfile CI .yarn İplik için varsayılan yaklaşım artık “ ” olduğundan ve eski yaklaşıma göre daha iyi performansa sahip olduğundan, kıyaslamaları yalnızca bu yaklaşımla kaydedeceğiz. Sıfır Kurulum Önbellek Olmadan Kilit Dosyaları Oluşturun Aldı bir dosyası oluşturması ve bağımlılıkları önbellek olmadan yüklemesi için. 16,5 saniye İpliğin yarn.lock Kullanılan komut: yarn install Mevcut Kilit Dosyalarından Bağımlılıkları Önbellek Olmadan Yükleme Aldı "Sıfır Kurulum" yaklaşımıyla ve herhangi bir önbellek olmadan bağımlılıkları kurması için. 11 saniye İpliğin Kullanılan komut: yarn install --frozen-lockfile Bağımlılıkları Global Önbellekle Mevcut Kilit Dosyalarından Yükleme Aldı “Sıfır Kurulum” yaklaşımı ve global önbellek ile bağımlılıkları kurması için. 8 saniye İpliğin Kullanılan komut: yarn install --frozen-lockfile Çalışma Alanlarını Yönet Tüm projeler için aynı anda ve belirli projeler için ayrı ayrı oluşturup bağımlılıkları yönetebildim. bir çalışma alanı Şu ana kadar kullandığım çalışma alanı özellikleri: Çalışma alanındaki tüm projeler için bağımlılıkları yükleyin. Tek bir spesifik proje için bağımlılıkları yükleyin. Tüm projeler için tek bir komut dosyasını aynı anda yinelemeli olarak çalıştırın. Belgeler gayet iyi ancak komut adları ve bayraklar biraz kafa karıştırıcı. Örneğin, ( ) ve iç içe geçmiş projesinde betiğini çalıştırmak için bunu yürütmem gerekiyor: root . b2b test yarn workspaces foreach -A --include '{.,b2b}' run test ile karşılaştırıldığında: Npm npm run test --workspace=b2b --include-workspace-root ppmpm şu sıralar ilgi görüyor; . pnpm pek çok şirket ve açık kaynaklı proje bunu kullanıyor Tıpkı gibi - yükleyicisiyle birlikte gelmez, dolayısıyla onu ayrıca yüklemeniz gerekir. Bu, işlem hatlarınızda ek bir adım olacağı anlamına gelir; proje bağımlılıklarınızı kurmadan önce ayarlamanız gerekir. iplik pnpm de Node.js CI pnpm'yi Bağımlılıkları Yönet olarak kabul edilir… pnpm “ ” Hızlı, disk alanından tasarruf sağlayan paket yöneticisi Aslında bağımlılıkların yerel olarak yönetilmesi açısından ifadesine katılıyorum. “disk alanının verimli olması” Varsayılan olarak, paylaşılan bağımlılıkların kopyalarını kaldırır. birden çok bağımlılıkta kullanılan paketler için sembolik bağlantılar oluşturur. yani, ve paketleri bağımlılık olarak paketini kullanıyorsa - paketini tek bir kopya olarak saklayacak ve ve paketleri için sembolik bağlantılar oluşturacaktır. Bu şekilde paket yöneticisi basılı kopyalar oluşturmaz ve SSD/HDD'nizde bellek tasarrufu sağlar. pnpm pnpm, a b c pnpm, c a b ℹ️ listelenen paketler için kayıtlarla ilgili bilgileri saklamaz. pnpm-lock.yaml ⚠️ bazen bağımlılıkları bir proje olarak tutmak yerine global önbellekte sakladığını unutmayın. Pnpm'nin pnpm-lock.yaml'yi Önbellek Olmadan Oluşturun Aldı bir oluşturması ve bağımlılıkları önbellek olmadan yüklemesi için. 31 saniye pnpm'nin pnpm-lock.yaml Kullanılan komut: pnpm install Bağımlılıkları pnpm-lock.yaml'den Global Önbellek Olmadan Yükleyin Aldı dosyasındaki bağımlılıkları önbellek olmadan yüklemesi için. 16 saniye pnpm'nin pnpm-lock.yaml Kullanılan komut: pnpm i --frozen-lockfile Bağımlılıkları Global Önbellekle Mevcut Kilit Dosyasından Yükleme Aldı genel önbellek ile dosyasındaki bağımlılıkları yüklemesi için. 5 saniye pnpm'nin pnpm-lock.yaml Kullanılan komut: pnpm i --frozen-lockfile Çalışma Alanlarını Yönet İşte işlerin gerçekten ilginç hale geldiği yer burası… çok sayıda yapılandırma seçeneği var, ancak bazı temel işlevler çalışmıyor! pnpm'de Karşılaştığım birkaç hatayı gözden geçirelim: pnpm kurulumu --filtre Yalnızca belirli projeler için bağımlılıklar kurabilmek önemlidir; çalışma alanındaki belirli projelerle ilgili işlem hatları oluşturduğunuzda monorepos için oldukça faydalıdır. yani, çalışma alanınızda olduğunuzu hayal edin: bir web uygulaması, arka uç sunucusu, test projesi (uçtan uca testler). Bunların hepsi ayrı projeleri ama aynı reponun parçaları ☝️ npm Artık bir işlem hattının yalnızca uçtan uca testler yürütmesini istiyorsunuz. Yani yalnızca uçtan uca test bağımlılıklarına ihtiyacınız var, değil mi? Bunu yapamazsınız - sizi tüm çalışma alanı için bağımlılıklar kurmaya zorluyor! pnpm yalnızca seçilen projeler için bağımlılıkları yüklemesi gerekiyordu, ancak çalışmıyor. pnpm install --filter <project-name> Bir yıllık bir hata var ve yakın zamanda çalışmayan bir düzeltmeyle kapatıldı. özyinelemeli kurulum=yanlış çalıştırdığınızda varsayılan olarak tüm çalışma alanı (tüm projeler) için bağımlılıkları yükler pnpm, pnpm install Çalışma alanı kökünüzdeki dosyasında ayarını yaparsanız bu davranışı değiştirebilirsiniz. .npmrc recursive-install=false AMA . neredeyse 2 yaşında olan başka bir hatayı tanıtıyor paylaşılan-çalışma alanı-kilit dosyası=yanlış varsayılan olarak bağımlılıklar listesini tek bir kilit dosyasında saklar ( ve ile aynı). pnpm npm iplik Çalışma alanı kökünüzdeki dosyasında ayarını yaparsanız bu davranışı da değiştirebilirsiniz. .npmrc shared-workspace-lockfile=false Bu, çalışma alanı özelliğini korumamıza ve belirli bir projeye yönelik bağımlılıkları yüklemek için işaretini kullanmamıza olanak tanır. --ignore-workspace Her neyse, bu ayar birkaç sorunu daha beraberinde getiriyor: ve hatlarımda hatası veriyor. eslint tsc --noEmit GitHub Eylemleri işlem "JavaScript Yığını Yetersiz" Bağımlılıklardan bazıları genel önbellekte saklanır ve dosyasında sembolik bağlantı oluşturulur. node_modules/.pnpm Performans Karşılaştırma Sonuçları # npm iplik ppmpm Bir kilit dosyası oluştur 60 saniye 16,5 saniye 31 saniye Bağımlılıkları önbellek olmadan yükleyin 18 saniye 11 saniye 8 saniye Bağımlılıkları genel önbellekle yükleyin 8 saniye 8 saniye 5 saniye Yukarıdaki karşılaştırmaya göre en yavaş paket yöneticisidir ☝️ npm Neyse bu sonuçları yorumlayalım… Kilit Dosyası Oluştur Bu nadir bir durumdur. Genellikle proje başlatıldığında bir kilit dosyası oluşturulur ve paketleri yüklediğinizde/güncellediğinizde genişler. Bunu akılda tutarak, bir paket yöneticisi seçtiğinizde güvenebileceğiniz çok önemli bir şey gibi görünmüyor. Bağımlılıkları Yükle Çoğu durumda, projeleriniz belirli bir bağımlılık listesi tutar ve nadiren bir şey ekler/kaldırırsınız. Büyük olasılıkla, zaman zaman paketlerinizin sürümlerini değiştireceksiniz; bu değişiklikler küçüktür ve geri kalan paketleri önbellekten yeniden kullanacaksınız. Başka bir deyişle, yaygın kullanım durumu şudur: Paket kayıt defterinden yeni paketler alın ve geri kalanını önbellekten alın. (5-8 sn), ortada (8-11 sn) ile (8-18 sn) neredeyse iki kat daha hızlıdır. pnpm iplik npm'den Çözüm Gerçekler gerçekten de paket yöneticisidir - mevcut incelemede bu oldukça açık! pnpm "hızlı ve diski verimli kullanan" bir çalışma alanı özelliğinde hata var ve bazı hatalar yıllardır çözülmedi. pnpm hem hem de CI boru hatlarında ek bir kurulum gerektirirken, gerektirmez. pnpm iplik, npm hem hem de paket kayıt defteri bilgilerini kilit dosyalarında saklamazken, bunu yapar. pnpm iplik, npm Yazarın Düşünceleri Paket yöneticisine olan gereksiniminiz "yalnızca bağımlılıkları yüklemek" kadar basitse, en iyi işi yapacağını düşünüyorum. pnpm'nin kutudan çıkan bir yükleyicisiyle birlikte gelmese de, veya ile CI ardışık düzenlerinde kurulumu kolaydır. Pnpm, Node.js corepack mevcut action tercih ediyorum çünkü: npm'yi kararlıdır (özellikle çalışma alanları), ile birlikte gelir ve CI hattında ek bir kurulum gerektirmez, Node.js paket kayıtlarını dosyasında saklar, böylece farklı kayıtlardan tek bir kapsamda bağımlılıklar yükleyebilirsiniz. package-lock.json Bu artılar, veya ile tasarruf edeceğim saniyelik hız ve disk alanından daha ağır basıyor. iplik pnpm Paket yöneticisi seçerken kriterleriniz nelerdir? Utanmayın ve aşağıdaki yorumlar bölümünde düşüncelerinizi bana bildirin! 👇😊
