Yarn vs Bun

Problem z Yarnem

#

Używałem Yarna Classic (1.x) od dłuższego czasu — lokalnie i w pipeline’ach CI/CD. Działał, ale dwie rzeczy regularnie mi przeszkadzały:

• Wolne instalacje w CI — nawet z cache’em yarn install był konsekwentnie najdłuższym krokiem w moich workflow’ach. Na średnim projekcie potrafił zająć 40–60 sekund, czasem więcej.
• Problemy z rozwiązywaniem zależności — co jakiś czas Yarn gubił się z peer dependencies albo generował lekko różniące się lockfile’e między środowiskami. Nic krytycznego, ale wystarczająco, żeby tracić czas na debugowanie.

Szansa dla Buna

#

Bun nie jest tak dojrzały jak Yarn czy npm. Jest młodszy, ekosystem wokół niego wciąż rośnie i miałem swoje wątpliwości. Ale obietnica szybszego package managera napisanego w Zigu z instalacją na natywnych prędkościach była trudna do zignorowania.

Podmieniłem więc yarn install na bun install w kilku pipeline’ach i uruchomiłem je równolegle na kilka tygodni.

Setup benchmarku

#

Wszystkie pomiary zostały wykonane na publicznych runnerach GitHub Actions (ubuntu-24.04, 4 vCPU, 16 GB RAM) na średniej wielkości projekcie JavaScript. Każdy scenariusz był uruchamiany wielokrotnie w celu potwierdzenia powtarzalności wyników.

• Wersja Yarna: 1.22.x (Classic)
• Wersja Buna: 1.3.x
• Cold install: bez cache’a, bez node_modules
• Warm install: globalny cache wypełniony, bez node_modules

Pełna konfiguracja benchmarku jest dostępna na github.com/emilgruzalski/yarn-vs-bun.

Wyniki

#

Różnica była natychmiastowa i powtarzalna między uruchomieniami. Cold install spadł z ponad 20 sekund do niecałych 2. Warm install kończył się w ułamku sekundy. W CI, gdzie pipeline’y uruchamiają się dziesiątki razy dziennie, ta redukcja szybko się kumuluje.

Dla kontekstu — dokumentacja Buna deklaruje do 25× szybsze instalacje w porównaniu z npm. Moje benchmarki porównują konkretnie z Yarnem Classic, więc liczby nie są bezpośrednio porównywalne z tym claimem — ale praktyczny wpływ na czas pipeline’ów mówi sam za siebie.

Kilka innych rzeczy, które rzuciły mi się w oczy:

• Brak problemów z zależnościami w testach — przez dwa tygodnie równoległych uruchomień bun install rozwiązał wszystko poprawnie. Żadnych konfliktów peer dependencies, żadnych phantom dependencies, żadnego dryfu lockfile’a między środowiskami. To ograniczona próbka — większe monorepa lub projekty z nietypowym grafem zależności mogą ujawnić edge case’y — ale w moim zakresie testów rozwiązywanie zależności było spójne.
• Drop-in replacement — Bun czyta package.json tak samo, obsługuje workspaces, overrides, a nawet automatycznie migruje z innych lockfile’ów. Przejście wymagało minimalnych zmian w konfiguracji.
• bun ci dla powtarzalnych buildów — odpowiednik --frozen-lockfile, failuje jeśli package.json nie jest zsynchronizowany z bun.lock. Dokładnie to, czego potrzebujesz w pipeline’ie.

Kwestia dojrzałości

#

Czy Bun jest gotowy na produkcję jako package manager? Na podstawie moich testów — tak, z zastrzeżeniami. Runtime Buna (jako zamiennik Node.js) to osobna rozmowa, ale jako package manager był stabilny w moich workflow’ach.

Format bun.lock zmienił się z binarnego na czytelny tekstowy w Bunie 1.2, co ułatwia diffy i code review. Lifecycle scripts są domyślnie sandboxowane (nie uruchamiają się, dopóki jawnie nie zaufasz pakietowi), co zmniejsza powierzchnię ataku w kontekście supply-chain — realna poprawa bezpieczeństwa względem domyślnego zachowania Yarna i npm.

Są jednak trade-offy, które warto wziąć pod uwagę:

• Dojrzałość ekosystemu — package manager Buna jest młodszy niż Yarn i npm. Edge case’y w dużych monorepo, prywatnych registry lub złożonych workflow’ach publikacji mogą istnieć, ale nie natknąłem się na nie.
• Społeczność i tooling — Yarn ma większą bazę pluginów, dokumentacji i wiedzy w społeczności. Rozwiązywanie problemów specyficznych dla Buna może wymagać więcej wysiłku.
• Stabilność wersji — Bun jest aktywnie rozwijany i może wprowadzać breaking changes między wersjami. Pinowanie wersji w CI jest wskazane.
• Yarn Classic vs Berry — te benchmarki zostały przeprowadzone przeciwko Yarn Classic (1.x). Yarn Berry (2.x+) z PnP lub linkerem node_modules może dać inne wyniki.

Werdykt

#

Na podstawie dwóch tygodni równoległego testowania na GitHub Actions, Bun okazał się stabilnym i znacząco szybszym zamiennikiem Yarna Classic jako package manager. Czasy instalacji spadły o rząd wielkości przy minimalnym nakładzie migracji.

Jeśli Twoje pipeline’y CI tracą zauważalny czas na yarn install, bun install jest wart sprawdzenia. Ścieżka migracji jest prosta, a zyski wydajnościowe natychmiastowe.