Yarn vs Bun

Problem z Yarnem

#

Używałem Yarna 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 zależnościami — 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 zbyt kusząca, żeby ją zignorować.

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

Co odkryłem

#

Różnica była natychmiastowa. Bun deklaruje do 25x szybsze instalacje w porównaniu z npm, a choć realne wyniki zależą od projektu, u mnie konsekwentnie widziałem 3-5x poprawę względem Yarna.

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

• Czasy instalacji spadły znacząco — to co Yarnowi zajmowało 45+ sekund, Bun kończy w mniej niż 15. W CI to się szybko kumuluje.
• Zero problemów z zależnościami — spodziewałem się przynajmniej jakichś edge case’ów, ale bun install rozwiązał wszystko poprawnie za każdym razem. Żadnych phantom dependencies, żadnego dryfu lockfile’a.
• 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 mojego doświadczenia — tak. Runtime Buna (jako zamiennik Node.js) to osobna rozmowa, ale jako package manager jest solidny. Obsłużył wszystko, co mu wrzuciłem, bez problemów.

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 jest fajnym bonusem od strony bezpieczeństwa.

Werdykt

#

Podszedłem sceptycznie, a wyszedłem przekonany. Bun jako package manager jest szybki, niezawodny i wart użycia w produkcyjnych pipeline’ach. Jeśli Twoje CI traci za dużo czasu na yarn install, daj szansę bun install — możesz się zdziwić.