npm vs Yarn vs pnpm vs Bun: kompletní srovnání pro rok 2026

Pro správu JavaScriptových závislostí máte v roce 2026 čtyři vážné uchazeče a propast mezi nimi nikdy nebyla větší. npm 11 přineslo min-release-age a npm trust pro posílení bezpečnosti dodavatelského řetězce. pnpm 10 nastavilo lifecycle skripty jako volitelné ve výchozím stavu. Yarn 4 dozrál se svým enginem Plug'n'Play a omezeními (constraints) založenými na JS. Bun 1.3 přidal katalogy závislostí, bun why a interaktivní aktualizace. Výběr nejlepšího správce balíčků pro node v roce 2026 už není o tom „npm je pomalé, zkuste něco jiného". Jde o to přiřadit správnou architekturu k vašemu projektu.

Toto srovnání správců balíčků JavaScriptu vám dává to, co většina průvodců vynechává: skutečné benchmarky rychlosti instalace na pojmenovaném hardwaru, srovnávací příklady kódu pro každý pracovní postup, reálná data z CI/CD pipeline a konkrétní rozhodovací rámec. Na základě našich zkušeností s budováním produkčních aplikací se všemi čtyřmi nástroji budete přesně vědět, který si vybrat.

Rychlé shrnutí: npm vs Yarn vs pnpm vs Bun na první pohled

Než se ponoříme do detailů, tady je to podstatné.

Zvolte pnpm, pokud chcete nejlepší celkovou rovnováhu rychlosti, správnosti a nástrojů pro monorepa. Zvolte Bun, pokud je vaší prioritou surová rychlost instalace a all-in-one runtime. Zvolte npm, pokud chcete nulovou konfiguraci u jednoduchého projektu. Zvolte Yarn Berry, pokud váš tým investoval do Plug'n'Play a zero-installs.

Nyní si přesně rozebereme, proč si každý nástroj zaslouží právě toto hodnocení.

Uchazeči: rychlé představení

npm, výchozí volba

npm se dodává s každou instalací Node.js. Tolik si ho nevyberete, jako spíš zdědíte. Verze 11 přinesla smysluplná vylepšení zabezpečení: min-release-age vám umožňuje odmítnout balíčky publikované před méně než X dny (snižuje riziko typosquattingu) a npm trust poskytuje konfiguraci pro ověřené vydavatele na úrovni jednotlivých příkazů. Stále je měřítkem, vůči kterému se poměřuje vše ostatní, a pro malé projekty funguje dobře.

Yarn, Classic vs Berry

Yarn vytvořil Facebook v roce 2016, aby vyřešil rané problémy npm se spolehlivostí. Zde je zásadní rozdíl: Yarn Classic (1.x) je v režimu údržby. Nezakládejte s ním nové projekty. Yarn Berry (2+, nyní v4) je moderní verze a je to zásadně odlišný nástroj. Jeho hlavní funkcí je Plug'n'Play (PnP), který zcela eliminuje node_modules ve prospěch souboru .pnp.cjs, jenž mapuje importy přímo. Yarn 4 také zahrnuje engine omezení (constraints) založený na JS pro vynucování pravidel napříč balíčky monorepa a automatickou správu @types.

pnpm, expert na efektivitu

pnpm znamená „performant npm" (výkonné npm) a svůj název si zaslouží. Jeho globální úložiště adresovatelné obsahem (content-addressable store) uchovává na disku jednu kopii každé verze balíčku a poté do node_modules každého projektu vytváří pevné odkazy (hard links). Výsledek: přísné řešení závislostí, které předchází fantomovým závislostem, úspora disku 50–70 % a rychlejší instalace než npm. Verze 10 udělala odvážný krok — lifecycle skripty jsou nyní ve výchozím stavu zakázány pomocí allowlistu onlyBuiltDependencies. Spouštění postinstall skriptů musíte explicitně povolit.

Bun, all-in-one runtime

Bun není jen správce balíčků. Postavený v Zig pro výkon na nativní úrovni, je to JavaScript runtime, bundler, test runner a správce balíčků v jednom. Verze 1.3 přinesla katalogy závislostí (centralizovaná správa verzí pro monorepa), bun why (vysledování, proč byl balíček nainstalován) a interaktivní bun update. Jeho rychlost instalace je opravdu ohromující — k číslům se brzy dostaneme.

Instalace a nastavení

Začátek práce s každým nástrojem vypadá jinak:

# npm -- ships with Node.js, nothing to install
npm --version

# Yarn -- use Corepack (recommended)
corepack enable
yarn init -2

# pnpm -- use Corepack or standalone install
corepack enable
pnpm --version
# or: npm install -g pnpm

# Bun -- standalone install
curl -fsSL https://bun.sh/install | bash
# or: brew install oven-sh/bun/bun

Corepack: oficiální způsob správy správců balíčků

Tady je něco, co většina průvodců vynechává: Corepack je zabudován do Node.js (od v16.9) a řeší problém „u mě to funguje" pro správce balíčků. Přidejte pole packageManager do vašeho package.json a každý vývojář ve vašem týmu automaticky použije přesně stejnou verzi:

{
  "name": "my-project",
  "packageManager": "[email protected]",
  "engines": {
    "node": ">=22.0.0"
  }
}

Jednou spusťte corepack enable a Corepack zachytí příkazy pnpm nebo yarn, stáhne a použije připnutou verzi. Žádné globální instalace ke správě, žádný rozptyl verzí napříč týmem. Bun zatím Corepack nepodporuje — jeho verzi budete muset připnout jinými prostředky (například souborem .tool-versions nebo konfigurací CI).

Srovnání CLI příkazů

Tato tabulka mapuje ekvivalentní příkazy napříč všemi čtyřmi správci. Přidejte si ji do záložek — budete se k ní vracet.

Pár poznámek: Bun používá bun add místo bun install <pkg> a skripty můžete spouštět jen pomocí bun dev (run je volitelné). pnpm a Yarn vám také umožňují spouštět skripty bez klíčového slova run. Rozdíl mezi npx/pnpx/yarn dlx/bunx mate spoustu vývojářů, takže mějte tuto tabulku po ruce.

Benchmarky rychlosti instalace: npm vs pnpm vs Yarn vs Bun

Tohle je to, kvůli čemu většina z vás přišla. Konsolidovali jsme data benchmarků z více zdrojů běžících na hardwaru Apple Silicon s aktuálními verzemi z roku 2026. Zde jsou časy cold instalace (bez mezipaměti, bez lockfile) pro dvě velikosti projektů:

Graf vypráví příběh na první pohled: sloupec Bunu je sotva viditelný vedle tyčící se 14,3sekundové instalace npm. pnpm a Yarn se pohybují uprostřed, ale ani zdaleka se neblíží cold instalaci Bunu pod jednu sekundu. U větších projektů se propast ještě zvětšuje — podívejme se na úplná čísla benchmarků.

Zdroj benchmarků: Pockit (leden 2026), M3 MacBook Pro, Node.js 22.x. Zkřížově ověřeno s benchmarky pnpm.io (8. února 2026) a edbzn/package-manager-benchmarks.

Čísla vyprávějí jasný příběh. Bun nainstaluje projekt s 50 závislostmi za 0,8 sekundy — to je 17× rychleji než npm a 5× rychleji než pnpm. U velkého monorepa s 800 závislostmi Bun dokončí za 4,8 sekundy, zatímco npm se stále trápí na 134 sekundách.

Proč je Bun tak rychlý? Tři důvody: je napsán v Zig (kompilovaný nativní kód, ne JavaScript), pro typickou instalaci používá zhruba 165 000 systémových volání oproti 1 000 000+ u npm a jeho binární lockfile (bun.lock) se parsuje rychleji než JSON nebo YAML.

Verdikt: Bun vyhrává v surové rychlosti. U cold instalací je Bun 3–5× rychlejší než pnpm a 10–17× rychlejší než npm. pnpm je silný druhý. Yarn Berry s PnP se otázce zcela vyhýbá tím, že eliminuje node_modules — pokud commitujete svou mezipaměť (zero-installs), není co instalovat.

Využití disku a efektivita úložiště

Rychlost není vše. Pokud pracujete na více projektech Node.js, využití disku se rychle sčítá. Zde je přehled, kam každý správce ukládá vaše závislosti a kolik místa to stojí:

Bun a Yarn PnP se shlukují dole v grafu, každý šetří přes polovinu místa na disku oproti npm. pnpm se na bázi jednoho projektu umisťuje uprostřed, ale jeho skutečná výhoda se projeví napříč více projekty — jak uvidíme v tabulce níže.

Data z benchmarků DevelopersVoice a analýzy Pockit (2025–2026). Přesná čísla se liší podle projektu.

Čísla pro jeden projekt jsou zajímavá, ale skutečný příběh se odehrává napříč více projekty. Představte si úložiště pnpm jako sdílenou knihovnu: místo toho, aby každý projekt dostal vlastní kopii každé knihy, všechny sdílejí stejnou knihovní kartu. Pokud máte 10 projektů Node.js používajících npm, můžete mít 5 GB duplicitních balíčků. S pnpm to klesá zhruba na 1,5 GB, protože globální úložiště vše deduplikuje.

Yarn Berry PnP volí jiný přístup — zcela eliminuje node_modules. Soubor .pnp.cjs mapuje každý import na jeho přesné umístění v mezipaměti. S zero-installs commitujete mezipaměť do repozitáře, takže klonování znamená nulový čas instalace.

Čísla Bunu na jeden projekt vypadají dobře, ale nesdílí balíčky napříč projekty tak jako pnpm. Napříč 10 projekty se úspory pnpm dramaticky sčítají.

Verdikt: pnpm vyhrává v efektivitě disku s velkým náskokem. Yarn Berry PnP je těsně za ním, pokud se zavážete k přístupu zero-install. npm a Bun neoptimalizují pro deduplikaci napříč projekty.

Hloubkový ponor do řešení závislostí

Výše uvedená čísla rychlosti a disku nejsou náhodná — jsou přímým důsledkem toho, jak každý nástroj řeší a ukládá závislosti. Pochopení architektury vám pomůže předvídat, jaké kompromisy děláte.

npm: problém hoistingu

npm používá plochý hoisting. Nainstaluje všechny vaše závislosti a jejich závislosti do jediné node_modules složky na nejvyšší úrovni. To vytváří problém zvaný fantomové závislosti: váš kód může import 'lodash', i když jste lodash nikdy nepřidali do package.json, jednoduše proto, že jiný balíček ho stáhl a npm ho vyzvedlo (hoist) na nejvyšší úroveň.

To funguje dobře... dokud aktualizace tranzitivní závislosti lodash neodstraní. Váš kód se rozbije v produkci bez varování, protože jste se spoléhali na balíček, který jste nikdy explicitně nenainstalovali.

Yarn Berry: už žádné node_modules

Plug'n'Play Yarn Berry volí nejradikálnější přístup. Neexistují žádné node_modules vůbec. Soubor .pnp.cjs obsahuje mapu každého balíčku na jeho přesné umístění na disku. To znamená rychlejší vyhledávání (žádný průchod souborového systému), žádné problémy s hoistingem a možnost zero-installs.

Háček? Některé balíčky předpokládají, že node_modules existuje. Pokud narazíte na problémy s kompatibilitou, můžete se vrátit pomocí nodeLinker: node-modules ve vašem .yarnrc.yml. Ale tím se vzdáte výhod PnP.

pnpm: přísné od návrhu

pnpm volí střední cestu. Vytváří adresář node_modules (takže kompatibilita nástrojů je vysoká), ale struktura je zásadně odlišná. Balíčky žijí v node_modules/.pnpm a jsou symlinkovány na místo. Na nejvyšší úrovni jsou přístupné pouze balíčky, které jste explicitně deklarovali v package.json.

To znamená žádné fantomové závislosti. Pokud jste to nepřidali do package.json, nemůžete to importovat. Váš kód selže rychle během vývoje, místo aby se záhadně rozbil v produkci o tři měsíce později.

Bun: rychlý, ale plochý

Bun používá stejnou strategii plochého hoistingu jako npm. Neřeší fantomové závislosti — upřednostňuje surovou rychlost před správností. Pokud přicházíte z npm, znamená to, že Bun je drop-in náhradou pro instalace, ale dědíte stejná rizika řešení závislostí.

Verdikt: pnpm vyhrává ve správnosti závislostí. Jeho přísné řešení zachytává skutečné chyby, které npm a Bun tiše skrývají. Yarn Berry PnP je ještě přísnější, ale vyžaduje více práce s kompatibilitou ekosystému. Pokud na správnosti závislostí vašemu týmu záleží (a mělo by), pnpm je pragmatická volba.

Podpora monorep a workspaces

Pokud spravujete více balíčků v jednom repozitáři, podpora workspaces je zásadním rozhodovacím faktorem. Zde je přehled, jak každý nástroj konfiguruje monorepo:

// npm and Bun: package.json
{
  "workspaces": ["packages/*", "apps/*"]
}

# pnpm: pnpm-workspace.yaml
packages:
  - "packages/*"
  - "apps/*"

# Yarn Berry: package.json workspaces field
# plus .yarnrc.yml for constraints
enableGlobalCache: false
nodeLinker: pnp

Srovnání funkcí workspaces

Filtrování pnpm je nejvyspělejší. Příkazy můžete spouštět proti konkrétním balíčkům podle názvu, adresáře nebo grafu závislostí: pnpm --filter @app/web... build spustí build pro balíček a všechny jeho závislosti. Engine JS constraints Yarn 4 je jedinečný — píšete pravidla v JavaScriptu, která vynucují politiky napříč celým monorepem (jako „všechny balíčky musí používat stejnou verzi Reactu").

U pnpm vs Yarn v monorepech záleží na filozofii. pnpm vynucuje správnost svým přísným modelem závislostí; Yarn ji vynucuje svým enginem constraints. Obojí funguje. Přístup pnpm vyžaduje méně konfigurace.

Verdikt: pnpm vyhrává pro workflow monorep. Jeho filtrování, přísné řešení závislostí a podpora protokolu workspace jsou nejvyspělejší. Yarn Berry je silný druhý se svým jedinečným enginem constraints. Workspaces npm fungují, ale postrádají pokročilé funkce. Bun rychle dohání s katalogy závislostí ve v1.3.

Srovnání zabezpečení

Útoky na dodavatelský řetězec proti balíčkům npm jsou skutečným a rostoucím problémem. Zde je přehled, jak vás každý nástroj chrání:

Největším rozlišovacím znakem je zpracování postinstall skriptů. Když spustíte npm install, npm ve výchozím stavu spustí všechny lifecycle skripty (install, postinstall, prepare) ze všech balíčků. To znamená, že kompromitovaný balíček může spustit libovolný kód na vašem stroji v okamžiku, kdy ho nainstalujete.

pnpm 10 a Bun tento výchozí stav obrací. Skripty jsou blokovány, pokud balíčky explicitně nepřidáte na whitelist v onlyBuiltDependencies (pnpm) nebo trustedDependencies (Bun). To je zásadní zlepšení zabezpečení. min-release-age u npm 11 je chytrý doplněk — můžete odmítnout balíčky publikované během posledních N dní, což zmenšuje okno pro útoky typosquattingu — ale je to volitelné, ne výchozí.

Verdikt: pnpm a Bun vedou v zabezpečení. Oba blokují lifecycle skripty ve výchozím stavu, což je nejúčinnější jednotlivá ochrana proti útokům na dodavatelský řetězec. min-release-age u npm 11 je chytrý doplněk, ale volitelný. Yarn je flexibilní, ale vyžaduje ruční konfiguraci.

CI/CD a výkon buildu

Volba správce balíčků přímo ovlivňuje náklady vaší CI/CD pipeline. Rychlejší instalace znamenají kratší buildy, což znamená nižší účty za infrastrukturu. Zde jsou data benchmarků GitHub Actions:

Bun ušetří 42 sekund u každé úlohy GitHub Actions oproti npm — smysluplný rozdíl, když spouštíte desítky buildů denně. pnpm se pohybuje uprostřed, zhruba o 26 sekund rychlejší než npm. Zde je úplný rozpis včetně konkrétně kroku instalace.

Zdroj: benchmarky Pockit GitHub Actions (leden 2026). Standardní pipeline buildu + testů Node.js.

Každý správce má v CI jinou strategii ukládání do mezipaměti. Zde je produkčně připravené nastavení pnpm pro GitHub Actions:

# .github/workflows/ci.yml
- uses: pnpm/action-setup@v4
  with:
    version: 10

- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'pnpm'

- run: pnpm install --frozen-lockfile
- run: pnpm build
- run: pnpm test

Pro optimalizaci Dockeru je klíčové vrstvení mezipaměti: zkopírujte lockfile před zdrojový kód, aby se instalace závislostí ukládaly do mezipaměti napříč buildy. To platí pro všechny čtyři správce.

Teď si promluvme o penězích. Pokud váš tým spouští 50 CI buildů denně a přechod z npm na pnpm ušetří 26 sekund na build, je to 21,6 minuty denně ušetřeno. Za měsíc je to 10,8 hodiny času CI. Při typické ceně GitHub Actions (0,008 $/min za Linux runnery) je to zhruba 5,18 $/měsíc — skromné pro malý tým, ale pro organizace spouštějící stovky buildů se úspory škálují lineárně. Skutečná výhra je čas vývojářů: rychlejší zpětné vazby znamenají vyšší produktivitu.

Pro hlubší pohled na jak platformy pro nasazení měří efektivitu buildu — volba správce balíčků je jednou z největších pák, které můžete zatáhnout.

Verdikt: Bun je v CI nejrychlejší. Ale pnpm nabízí nejlepší rovnováhu rychlosti, ukládání do mezipaměti a kompatibility s ekosystémem. Skutečné úspory pocházejí z rychlejších instalací v CI pipeline, zejména ve velkém měřítku.

Kompatibilita s frameworky

Správce balíčků nevybíráte ve vakuu — vybíráte ho pro konkrétní framework a projekt. Zde je přehled, co skutečně funguje a co doporučují tvůrci frameworků:

Dobrá zpráva: každý moderní framework funguje se všemi čtyřmi správci. Nuance se týkají kompatibility Bunu a Yarn PnP.

Bun tvrdí 98% kompatibilitu s npm. Zbývající 2 % zahrnují některé nativní moduly používající node-gyp, určité postinstall skripty, které předpokládají chování npm, a okrajové případy s řešením peer dependencies. Před závazkem otestujte svůj konkrétní projekt.

Yarn PnP má širší problémy s kompatibilitou. Některé balíčky předpokládají, že node_modules existuje na disku. Pokud narazíte na problémy, nastavte nodeLinker: node-modules v .yarnrc.yml jako záložní řešení, ale tím se vzdáte výhod PnP.

Při přemýšlení o volbě nástrojů pro build je správce balíčků jen jedním dílkem. Ale je to dílek, se kterým pracujete desítkrát denně, takže stojí za to ho mít správně.

Verdikt: npm má nejlepší kompatibilitu (je univerzální výchozí volbou). pnpm je těsně druhý s nulovými praktickými problémy s kompatibilitou pro standardní projekty. Bun funguje v 98 % případů. Yarn PnP vyžaduje testování kompatibility.

Připravenost Bunu pro produkci: realita roku 2026

Každý článek buď vynáší Bun jako budoucnost, nebo ho zavrhne jako příliš nezralý. Zde je naše upřímné hodnocení.

Co v roce 2026 funguje dobře:

• bun install je drop-in kompatibilní s většinou projektů npm. Nepotřebujete přepínat runtime — stačí používat Bun jako správce balíčků s Node.js
• Binární lockfile (bun.lockb) byl nahrazen textovým bun.lock pro lepší git diffy
• Katalogy závislostí a bun why ho přibližují úrovni nástrojů pro monorepa u pnpm
• Anthropic používá Bun pro nástroje Claude Code. Další významné společnosti ho přijaly pro interní nástroje

Známé okrajové případy:

• Nativní moduly používající node-gyp mohou selhat
• Některé postinstall skripty předpokládají chování specifické pro npm
• Podpora Windows je novější a méně prověřená než Linux/macOS
• Řešení peer dependencies má občasné rozdíly oproti npm
• Některá prostředí CI vyžadují explicitní instalaci Bunu (není předinstalován jako npm)

Praktická cesta přijetí: bun install můžete používat bez přechodu na runtime Bun. Toto je nejnižší rizikový způsob, jak získat výhody rychlosti Bunu. Váš kód stále běží na Node.js, vaše testy stále používají váš stávající runner, ale vaše node_modules se naplní 10× rychleji. Pokud to funguje dobře, můžete postupně přijmout více z toolkitu Bun.

Je Bun připraven pro produkci v roce 2026? Jako správce balíčků ano, s testováním. Jako plná náhrada runtime za Node.js pečlivě vyhodnoťte vůči vašim konkrétním závislostem.

Průvodce migrací

npm na pnpm (nejpopulárnější migrace)

Toto je nejjednodušší cesta migrace. pnpm čte lockfile npm nativně:

1. Nainstalujte pnpm: corepack enable, poté přidejte "packageManager": "[email protected]" do package.json
2. Importujte svůj lockfile: pnpm import (převede package-lock.json na pnpm-lock.yaml)
3. Uklidit: smažte node_modules a package-lock.json
4. Instalujte: pnpm install
5. Otestujte vše: spusťte build, testy a vývojový server
6. Aktualizujte konfiguraci CI: přepněte na pnpm/action-setup v GitHub Actions

npm na Bun (nejrychlejší cesta)

Ještě jednodušší — Bun čte package-lock.json přímo:

1. Nainstalujte Bun: curl -fsSL https://bun.sh/install | bash
2. Spusťte: bun install (vygeneruje bun.lock)
3. Otestujte: některé postinstall skripty mohou vyžadovat trustedDependencies v package.json
4. Aktualizujte CI: přidejte krok instalace Bunu

Shrnutí obtížnosti migrace

Tip pro profesionály: Nemigrujte uprostřed sprintu. Vyhraďte si čas, otestujte celou pipeline buildu a mějte plán pro návrat. Pro většinu týmů je migrace z npm na pnpm opravdu bezbolestná.

Kdy použít co: rozhodovací rámec

Tady je sekce, kvůli které přišel každý čtenář. Konkrétní doporučení podle scénáře:

Pokyny podle velikosti týmu

Jak Techsy přistupuje k výběru správce balíčků

V Techsy jsme dodali produkční aplikace se všemi čtyřmi správci balíčků. Zde je, co jsme se naučili tvrdou cestou:

• Naším výchozím je pnpm pro většinu klientských projektů. Přísné řešení závislostí zachytí problémy fantomových závislostí dříve, než se dostanou do produkce. Úspora disku je důležitá, když náš tým pracuje na 10+ projektech současně. A Corepack činí nástup nových vývojářů bezbolestným — naklonují repozitář, spustí pnpm install a vše prostě funguje.

• Bun používáme pro interní nástroje, CLI skripty a prototypy, kde na rychlosti záleží nejvíce. Také používáme bun install s runtime Node.js pro některé klientské projekty — dává nám to rychlost instalace Bunu bez závazku k plnému runtime Bun.

• npm používáme pro rychlé prototypy a klientské projekty, kde tým už má základ v npm a náklady na migraci nejsou ospravedlnitelné. npm je v pořádku. Ne vše musí být optimalizováno.

• Yarn Berry doporučujeme pro specifická klientská prostředí, která potřebují zero-installs nebo mají stávající infrastrukturu PnP. Je to specializovaný nástroj pro specializovanou potřebu.

Náš standardní proces pro nové projekty: vyhodnotit potřeby monorepa projektu, zkontrolovat omezení CI pipeline, zvážit obeznámenost týmu a jako výchozí zvolit pnpm, pokud neexistuje konkrétní důvod proč ne.

Zakládáte nový projekt a chcete mít nástroje správně od prvního dne? Náš tým dodal produkční aplikace se všemi čtyřmi správci balíčků. Získejte bezplatnou konzultaci architektury.

Závěrečný verdikt: npm vs Yarn vs pnpm vs Bun v roce 2026

Pokud v roce 2026 vybíráte správce balíčků, pnpm je nejbezpečnější sázkou pro většinu týmů. Je rychlý, efektivní na disk, přísný ohledně závislostí a má nejlepší nástroje pro monorepa. Bun je vzrušující budoucnost — použijte ho, když je rychlost vaší hlavní prioritou nebo chcete all-in-one toolkit. npm je v pořádku pro jednoduché projekty, kde nechcete přemýšlet o nástrojích. Yarn Berry je specializovaná volba pro týmy, které chtějí jedinečné výhody PnP.

Nejlepší správce balíčků je ten, na kterém se shodne celý váš tým. Vyhodnoťte potřeby svého projektu, vyberte jeden, připněte ho pomocí Corepack a začněte budovat.

Zdroje

• Dokumentace npm, oficiální reference a průvodci npm CLI
• Dokumentace pnpm, oficiální dokumentace pnpm, včetně benchmarků a průvodců migrací
• Dokumentace Yarn, oficiální dokumentace Yarn Berry (v4) a reference Plug'n'Play
• Dokumentace Bun, oficiální dokumentace Bun pokrývající runtime, správce balíčků a nástroje
• Benchmarky pnpm.io, oficiální benchmarky rychlosti instalace pnpm (8. února 2026)
• edbzn/package-manager-benchmarks, open-source sada benchmarků porovnávající npm, Yarn, pnpm a Bun

Často kladené otázky

Který je nejrychlejší správce balíčků JavaScriptu?

Bun, s výrazným náskokem. V benchmarcích na M3 MacBook Pro nainstaluje Bun projekt s 50 závislostmi za 0,8 sekundy oproti 14,3 sekundy u npm. pnpm je nejrychlejší nativní volba pro Node.js s 4,2 sekundy pro stejný projekt.

Je pnpm lepší než npm?

Pro většinu projektů ano. pnpm je rychlejší, používá méně místa na disku (úspora 50–70 % napříč projekty), předchází fantomovým závislostem a má lepší podporu monorep. Kompromis: mírně strmější počáteční křivka učení a vzácné okrajové případy se staršími balíčky, které předpokládají ploché node_modules.

Je Bun připraven pro produkci v roce 2026?

Jako správce balíčků ano. bun install funguje s projekty Node.js a je 98% kompatibilní s npm. Bun můžete používat jako správce balíčků bez přepínání runtime. Jako plná náhrada runtime za Node.js pečlivě otestujte své konkrétní závislosti před závazkem.

Měl bych přejít z npm na pnpm?

Pokud pracujete na více projektech nebo monorepech, ano. Migrace je téměř drop-in: spusťte pnpm import pro převod lockfile, smažte node_modules a spusťte pnpm install. Pokud máte jeden malý projekt a npm nezpůsobuje problémy, není spěch.

Nahrazuje Bun npm?

Bun může nahradit npm jako správce balíčků, ale je také mnohem víc: JavaScript runtime, bundler a test runner. Můžete používat jen bun install, aniž byste nahradili Node.js jako svůj runtime. Představte si to jako používání Bunu pro to, co umí nejlépe (rychlé instalace), zatímco pro vše ostatní si ponecháte svůj stávající stack.

Je Yarn v roce 2026 stále relevantní?

Yarn Berry (v4) je relevantní pro týmy, které chtějí Plug'n'Play a zero-installs. Jeho engine JS constraints je opravdu jedinečný. Nicméně Yarn Classic (v1) je v režimu údržby a měl by se od něj migrovat. Pokud jste na Yarn Classic, přejděte na pnpm nebo Yarn Berry.

Co jsou fantomové závislosti?

Balíčky, které můžete importovat ve svém kódu, i když jste je nikdy nepřidali do package.json. Objevují se, protože npm a Yarn Classic vyzvedávají (hoist) tranzitivní závislosti na začátek node_modules. Váš kód funguje, dokud aktualizace závislosti tento tranzitivní balíček neodstraní — pak se rozbije v produkci. pnpm tomu předchází přísným řešením závislostí.

Který správce balíčků je nejlepší pro monorepa?

pnpm. Má nejvyspělejší filtrování workspaces (--filter), přísnou izolaci závislostí mezi balíčky a podporu protokolu workspace (workspace:*). Yarn Berry je silný druhý se svým enginem constraints. Bun dohání s katalogy závislostí ve v1.3.

Co je Corepack?

Nástroj zabudovaný do Node.js (od v16.9), který spravuje verze správců balíčků. Přidejte "packageManager": "[email protected]" do vašeho package.json a spusťte corepack enable. Corepack zajistí, že každý vývojář a CI runner použije přesně tuto verzi — žádné ruční instalace, žádný rozptyl verzí.

Mohu používat Bun s existujícími projekty npm?

Ano. Spusťte bun install v jakémkoli projektu s package.json. Bun čte soubory package-lock.json a yarn.lock. Nepotřebujete měnit strukturu projektu a váš kód stále běží na Node.js.

Jak migruji z npm na pnpm?

Spusťte pnpm import pro převod package-lock.json na pnpm-lock.yaml, smažte node_modules a package-lock.json, spusťte pnpm install a poté otestujte svou pipeline buildu. Celý proces trvá u většiny projektů asi 30 minut.

Jaký správce balíčků používá Next.js?

Next.js funguje se všemi čtyřmi. create-next-app má jako výchozí npm, ale podporuje příznaky --use-pnpm, --use-yarn a --use-bun. Platforma CI Vercel nativně podporuje pnpm a komunita Next.js silně preferuje pnpm pro jeho přísné řešení závislostí a podporu monorep.