pnpm'in disk tasarrufu monorepolarda parlıyor; küçük projeler için npm daha basit bir tercih olmaya devam ediyor

jtorchia'nın dev.to'da yayımladığı bir karşılaştırma, npm mi pnpm mi sorusunun hız benchmark'larından çok deponuzun şekline göre belirlendiğini savunuyor: pnpm'in paylaşımlı deposu monorepolarda ve önbellekli CI pipeline'larında ölçülebilir tasarruf sağlarken, npm küçük ve tek paketli projeler için pragmatik varsayılan olmaya devam ediyor.

Her paket yöneticisi diske ne yazıyor

Gönderiye göre npm, her bağımlılığın fiziksel bir kopyasını node_modules içine yazıyor. Dört paketin de aynı lodash sürümünü bildirdiği bir workspace'te, agresif hoisting'e bel bağlamadığınız sürece bu kopya ağaçta birden fazla yerde bulunabiliyor — yazarın da belirttiği üzere bu taktik, kendine has phantom-dependency sorunlarını beraberinde getiriyor.

Gönderide alıntılanan motivasyon dokümanına göre pnpm farklı bir mimari yol izliyor: her paket sürümü, projenin dışında konumlanan global bir content-addressable depoya yalnızca bir kez indiriliyor ve bir repodaki node_modules dizinleri bu depoyu gösteren symlink'ler tutuyor. Bir makinedeki on proje aynı kütüphane sürümünü kullanıyorsa, o sürüm diskte tam olarak bir kez var oluyor.

Yazarın merkezindeki nokta bu modelden kaynaklanıyor: tasarruf, toplam bağımlılık sayısıyla değil, workspace içinde bağımlılık paylaşan paketlerin sayısıyla ölçekleniyor. On üretim bağımlılığı olan tek başına bir package. dosyası, symlink modeline yinelenmesini azaltacak hiçbir şey vermiyor.

Kurulum süresi ise daha koşullu. Bir paket zaten yerel depodaysa pnpm onu indirmeyi atlayabiliyor; önbelleği soğuk bir CI runner'ında ise ilk indirme her iki yöneticide de aynı ağırlıkta. Disk tasarrufu tutarlı — zaman tasarrufu değil.

Migration sürtünmesi nerede gizleniyor

Gönderi tanıdık bir diziyi anlatıyor: küçük bir Next.js projesi, pnpm'i öven bir yazıyı okuyan biri tarafından migrate ediliyor ve maliyet sonradan, projenin dışında ortaya çıkıyor. npm ci çalıştıran CI script'leri ve Docker imajları, package-lock. dosyasını ayrıştıran bağımlılık linter'ları pnpm-lock.yaml ile ne yapacaklarını bilmiyorlar.

Sıkılık faturayı büyütüyor. pnpm, npm'in hoisting'i sessizce erişilebilir kıldığı bildirilmemiş bağımlılıkları reddediyor; dolayısıyla o phantom paketlere bel bağlayan script'ler ERR_PNPM_NO_MATCHING_VERSION hatasıyla başarısız olmaya başlayabiliyor. Ekip üyelerinin ayrıca .pnpmfile.cjs dosyasını ve symlink tabanlı bir düzeni nasıl debug edeceklerini öğrenmeleri gerekiyor.

Bir karar matrisi

Yazar birkaç senaryo çiziyor:

• Bağımlılık paylaşan üç veya daha fazla paketli monorepolar: gerçek tasarruf; paketler arasında kaç bağımlılığın örtüştüğüne bakın.

• Çalıştırmalar arasında bağımlılık önbelleklemesi yapan CI: runner yalnızca lockfile'ı değil, global depoyu da önbellekleyebiliyorsa değer.

• Workspaces'siz tek bir proje: marjinal kazançlar; ekibin pnpm'i zaten bilip bilmediğini yoksa eğitime ihtiyaç duyup duymadığını tartın.

• Çok aşamalı Docker build'leri: duruma göre değişir — Dockerfile'ın depoyu kopyalayacak şekilde ayarlanması gerekir ve imaj boyutu tasarrufu bu değişikliği haklı çıkarabilir de çıkarmayabilir de.

• Olgun bir CI/CD kurulumunda npm'e özgü script'lere sahip ekipler: bu script'ler yeniden yazılmadıkça değmez.

Matris bir başlangıç noktası, yazarın uyardığı gibi, kendi projenizde ölçüm yapmanın yerini tutmuyor.

Workspaces ve daha derindeki fark

npm, v7'den beri workspaces'i destekliyor ve bağımlılıkları monorepo köküne doğru hoist ediyor. Bu çalışıyor, gönderi bunu kabul ediyor; ancak aynı makinedeki farklı monorepolar arasında yinelenmeyi azaltmıyor — her repo kendi fiziksel kopyasını yeniden indirip depoluyor. Buna karşılık pnpm'in workspace:* protokolü, kardeş paketleri registry'den geçmeden doğrudan symlink'liyor.

Yazar bu açığı eksik bir özellik değil, mimari bir fark olarak çerçeveliyor: iki yönetici, byte'ların nerede yaşadığı konusunda aynı fikirde değil.

Karşılaştırmanın size söyleyemediği şeyler

Gönderi sınırları hakkında açık: özgün bir kurulum süresi benchmark'ı içermiyor. Depolama modelinden, yinelenmenin azaltılmasının workspace boyutuyla ölçeklendiği çıkarılabilir; ancak pnpm'in belirli bir CI çalışmasında ne kadar zaman kazandırdığı — bu runner'a, önbellek boyutuna ve ağa bağlı — ya da disk tasarrufunun Docker yapılandırmasını ve lockfile'a bağımlı araçları yeniden yazmayı haklı çıkarıp çıkarmadığı sonucuna varamıyorsunuz. Symlink başına farklı ikili dosyalar derleyen native bağımlılıklar, pnpm'in sürtünme ekleyebildiği ve gönderinin ele almadığı bir durum olarak işaretleniyor.

Bir ekip kararı için dürüst bir sayıya giden yol, yazarın yazdığı gibi, her iki installer'ı aynı projede, aynı soğuk önbellekle çalıştırmak ve kendinizin ölçmesi.

Neden önemli

Paket yöneticisi seçimi çoğu zaman bir zevk meselesi olarak tartışılıyor ya da hype peşinden koşularak yapılıyor. Bu karşılaştırma, bunu maliyetleri install komutunun dışında — CI script'lerinde, Docker tariflerinde ve npm'in davranışını sessizce varsayan linter'larda — ortaya çıkan mimari bir karar olarak yeniden çerçeveliyor. Monorepo ekipleri için pnpm'in content-addressable deposu, her workspace paketiyle büyüyen bir yineleme sorununa saldırıyor; tek paketli bir uygulama için ise aynı mekanizma, optimize edecek az şey varken bir öğrenme eğrisi ekliyor. Hangi durumda olduğunuzu bilmek ve migrate etmeden önce ölçmek, asıl çıkarım.