Bun 1.4 Wbudowane narzędzia, które mogą zastąpić sharp, Puppeteer, node-pty i inne
Praktyczny przewodnik po wbudowanych funkcjach Bun 1.4: obsługa obrazów, przeglądarka, Markdown, cron, terminal, skrypty równoległe oraz testy, wraz z instrukcjami dotyczącymi bezpiecznego wypróbowywania ich w rzeczywistych projektach.
Zwykły projekt w JavaScriptu gromadzi zależności dla każdej funkcjonalności, której potrzebuje: sharp do obsługi obrazów, parser Markdown, Playwright lub Puppeteer do automatyzacji przeglądarek, bibliotekę cron, node-pty do pseudo-terminali, concurrently lub npm-run-all do uruchamiania skryptów równolegle, a także mnóstwo konfiguracji CI w celu przyspieszenia testów. Bun 1.4 przyjmuje inne podejście: wiele z tych funkcji może być realizowanych bezpośrednio w środowisku wykonawczym. Ten przewodnik przedstawia nowe wbudowane narzędzia wraz z przykładami kodu potrzebnymi do ich wypróbowania oraz proponuje bezpieczny sposób na ich ocenę.
Zgodnie z komunikatem o wydaniu, Bun 1.4 trafił na rynek 20 sierpnia 2026 roku, dodając ponad 1 500 testów kompatybilności z Node.js, naprawiając ponad 2 900 problemów oraz zmniejszając zużycie CPU i pamięci w stanie bezczynności. API w tej nowej wersji mogą się nadal zmieniać, dlatego traktuj podane poniżej informacje jako wycinek stanu rzeczy i sprawdź je w oficjalnym komunikacie o Bun 1.4 oraz aktualnej dokumentacji. Głównym celem tego wydania nie jest tyle zwiększenie szybkości, co skrócenie całego zestawu narzędzi.
Instalacja lub aktualizacja
Bun można zainstalować za pomocą skryptu shell, npm, Homebrew, PowerShell w systemie Windows lub jako obraz Dockera. Każda oznaczona poniżej linia to jedna z alternatyw – wybierz tę, która pasuje do twojego środowiska:
--curl
curl -fsSL https://bun.sh/install | bash
--npm
npm install -g bun
--brew
brew install oven-sh/bun/bun
--powershell
powershell -c "irm bun.sh/install.ps1 | iex"
--docker
docker pull oven/bun
Jeśli Bun jest już zainstalowany na twoim komputerze, jeden poleceń przeniesie cię do najnowszej wersji:
bun upgrade
Przetwarzanie obrazów za pomocą Bun.Image
Bun.Image umożliwia dekodowanie, zmianę rozdzielczości, obrót oraz kodowanie popularnych formatów w czasie wykonywania, dzięki czemu nie jest już konieczna zależność od natywnych bibliotek do obsługi obrazów. Poniższy łańcuch operacji odczytuje plik JPEG, umieszcza go w prostokącie o wymiarach 1024 na 1024, zachowując przy tym stosunek aspektów, obraca go, koduje jako WebP o jakości 85 i zapisuje wynik:
await Bun.file("photo.jpg")
.image()
.resize(1024, 1024, { fit: "inside" })
.rotate(90)
.webp({ quality: 85 })
.write("thumb.webp");
Ponieważ każdy krok zwraca ten sam obiekt budujący, cała ścieżka przetwarzania jest realizowana od góry do dołu, podobnie jak w przepisie kulinarnym. Typowe zastosowania to tworzenie miniatur do przesyłania, zmiana rozdzielczości awatarów, konwersja plików JPEG na WebP, korzystanie z API do obsługi obrazów oraz optymalizacja plików przed ich przechowywaniem.
Bun donosi, że jego implementacja przewyższa sharp w kilku własnych testach wydajnościowych, w tym przy zmianie rozdzielczości i kodowaniu pliku PNG w formacie 1080p. Dodatkową zaletą jest usunięcie modułu natywnego, który często komplikuje proces budowania aplikacji w Dockerze oraz korzystanie z pamięci cache w środowiskach CI. Jeśli polegasz na zaawansowanych funkcjach sharp, sprawdź przed przejściem, czy operacje, których używasz, są dostępne.
Autoryzacja przeglądarki bez interfejsu graficznego za pomocą Bun.WebView
Bun.WebView to wbudowana API przeglądarki bez interfejsu graficznego, która umożliwia nawigację, klikanie, przewijanie, wykonywanie kodu JavaScript oraz robienie zrzutów ekranu. Zwróć uwagę na deklarację await using: łączy ona czas życia widoku z otaczającym kontekstem, dzięki czemu przeglądarka jest automatycznie zwalniana po zakończeniu bloku, nawet w przypadku błędów.
await using view = new Bun.WebView({
width: 800,
height: 600,
});
await view.navigate("https://bun.sh");
await view.click("a[href='/docs']");
const title = await view.evaluate("document.title");
await Bun.write(
"page.png",
await view.screenshot()
);
Skrypt otwiera stronę, klika w link, odczytuje tytuł dokumentu i zapisuje screenshot. Dzięki temu można wykonać wiele małych zadań bez konieczności używania pełnego frameworku automatyzacji: usług do robienia screenshotów, testów sprawdzających podstawowe funkcje, narzędzi do scrapingu, kontrolerów czasu dostępności, sprawdzaczy linków oraz prostych procesów QA. Gdy potrzebna jest kontrola na niższym poziomie, Bun.WebView umożliwia dostęp do protokołu Chrome DevTools Protocol. W przypadku dużych zestawów testowych typu end-to-end wymagających obsługi różnych przeglądarek, dedykowane narzędzie jest prawdopodobnie lepszym rozwiązaniem.
Renderyzowanie Markdown za pomocą Bun.markdown
Bun.markdown przekształca pliki Markdown do kilku formatów docelowych. Najprostszy z nich zwraca ciąg HTML:
const html = Bun.markdown.html(
"# Hello **world**"
);
Może również bezpośrednio generować elementy React, co jest przydatne, gdy komponent renderuje stronę README lub dokumentację:
export default function Page() {
return Bun.markdown.react(readme);
}
Renderyzację można dalej dostosować, na przykład aby sformatować wyświetlanie treści w terminalu. Obsługiwane są rozszerzenia Markdown w stylu GitHub, takie jak tabele, listy zadań, podkreślanie tekstu i automatyczne linki. Jest to odpowiednie dla stron dokumentacyjnych, portali programistów, blogów, narzędzi do przeglądania plików README, pomocy w interfejsie linii poleceń, baz wiedzy oraz interfejsów wyświetlających Markdown generowany przez modele.
Jedna kwestia ma większe znaczenie niż pozostałe: wyjście w formacie HTML nie jest oczyszczane. Każdy tekst w formacie Markdown od użytkowników, podmiotów trzecich lub modeli językowych musi przejść przez narzędzie oczyszczania, zanim trafi do przeglądarki, w przeciwnym razie istnieje ryzyko infekcji skryptami.
Zadania zaplanowane za pomocą Bun.cron
Bun.cron() działa w dwóch trybach. W pierwszym rejestruje zadanie u planerów systemu operacyjnego: crontab w Linux, launchd w macOS oraz Task Scheduler w Windows. Funkcja ta przyjmuje ścieżkę do skryptu, wyrażenie cron oraz nazwę zadania; to ostatnie uruchamia proces co poniedziałek o godzinie 02:30:
await Bun.cron(
"./worker.ts",
"30 2 * * MON",
"weekly-report"
);
Ponieważ planowanie jest kontrolowane przez system operacyjny, zadanie jest wykonywane nawet wtedy, gdy nie ma aktywnego procesu Bun. W drugim trybie planowanie znajduje się wewnątrz bieżącego procesu, który uruchamia zadanie co pięć minut. Deklaracja using zatrzymuje zadanie po zakończeniu jego zakresu działania:
using job = Bun.cron(
"*/5 * * * *",
async () => {
await cleanupTempFiles();
}
);
Wykonania nigdy się nie nakładają, a obsługiwane są wyraźne strefy czasowe. Dobrymi kandydatami na zastosowanie są zadania czyszczeniowe, generowanie raportów, konserwacja bazy danych, synchronizacja danych, przetwarzanie wiadomości e-mail w partiach oraz okresowe sprawdzanie stanu. Należy pamiętać, że zadania wewnątrz procesu znikają po ponownym uruchomieniu procesu, a jeśli uruchamiasz kilka replik, każda z nich zostanie wykonywana, chyba że dodasz mechanizm koordynacji.
Wykonywanie skryptów równolegle
bun run --parallel zastępuje concurrently i npm-run-all. Przekaż kilka nazw skryptów, aby wykonać je jednocześnie:
bun run --parallel build test
Wzory globowe służą do wybrania grupy skryptów:
bun run --parallel "build:*"
W połączeniu z flagą --filter ta sama flaga sprawia, że skrypt jest wykonywany we wszystkich przestrzeniach roboczych:
bun run --parallel --filter '*' build
Zwykle jedna niepowodzenie zatrzymuje wszystko; flaga --no-exit-on-error pozwala pozostałym zadaniom zostać ukończonym, co jest przydatne do jednoczesnego zebrania wszystkich niepowodzeń testów:
bun run --parallel --no-exit-on-error --filter '*' test
Każdy wiersz wyjścia jest poprzedzony informacją o skrypcie, który go wygenerował, dzięki czemu logi mieszane pozostają czytelne. W monorepo zastępuje to sekwencyjną kolejność działania na rzecz rozproszonego obliczania pomiędzy rdzeniami CPU.
package A → build
package B → build
package C → build
Procesy równoległe nie rozumieją zależności między pakietami, więc jeśli jeden pakiet musi zostać zbudowany przed drugim, nadal potrzebna jest określona kolejność lub narzędzie do zarządzania zadaniami, które modeluje te zależności.
Szybsze wykonywanie testów
bun test posiada flagę --parallel:
bun test --parallel
Można wyraźnie ustalić liczbę procesów roboczych:
bun test --parallel=4
Pliki są dynamicznie przekazywane procesom roboczym, zamiast być wcześniej dzielone na stałe grupy, dzięki czemu jeden wolny plik nie powoduje bezczynności innych procesów. Trzy powiązane flagi dotyczą środowiska CI. Mechanizm sharding dzieli zestaw testów między różne maszyny – tutaj pokazano pierwszą z trzech grup:
bun test --shard=1/3
Uruchamianie tylko testów dotkniętych twoimi zmianami skraca lokalne pętle zwrotne:
bun test --changed
Zapisywanie czasu trwania pozwala na równomierne rozkładanie pracy podczas późniejszych uruchomień przy użyciu rzeczywistych danych czasowych:
bun test --timings=timings.json
Wykonanie równoległe ujawnia testy, które dzielą stan, takie jak wspólna baza danych, stałe porty lub pliki tymczasowe. Spodziewaj się konieczności naprawienia niektórych problemów z izolacją po pierwszym włączeniu tej funkcji.
Naprawa podatnych zależności
Dla utrzymania bezpieczeństwa dostępna jest wbudowana komenda:
bun audit fix
Uaktualnia ona podatne pakiety do poprawionych wersji i je instaluje. Gdy naprawa wymaga podniesienia wersji głównej, Bun zgłasza to zamiast ją zastosować; dodaj --latest, aby to włączyć. Przeanalizuj te większe aktualizacje tak jak każdą zmianę łamiącą funkcjonalność. W środowisku CI bezpieczeństwo zależności jest łączone z normalnym krokiem instalacji.
Usuwanie duplikatów zależności
W dużych projektach często występuje kilka niemal identycznych wersji jednego pakietu:
esbuild@0.15.10
esbuild@0.15.11
Gdy jedna wersja spełnia wszystkie wymagania, ten polecenie łączy duplikaty:
bun dedupe
Wariant sprawdzania zawodzi z błędem, gdy duplikaty pozostają, co czyni go naturalną bramą w procesie CI:
bun dedupe --check
Mniej duplikatów oznacza mniejsze drzewa zależności, szybszą instalację, mniej wykorzystania dysku, prostsze utrzymanie oraz potencjalnie mniejsze rozwiązania do wdrożenia.
Kierowanie programami interaktywnymi za pomocą Bun.Terminal
Bun.Terminal to wbudowany pseudo-terminál, który umożliwia JavaScriptowi kontrolowanie programów interaktywnych bez użycia node-pty:
bash
vim
htop
Pseudo-terminał jest ważny, ponieważ takie programy zachowują się inaczej, gdy wykrywają prawdziwy terminal: wyświetlają interfejsy pełnoekranowe, używają kolorów i oczekują naciskania klawiszy. Dlatego Bun.Terminal jest istotny dla narzędzi deweloperskich, interfejsów linii poleceń, paneli sterowania terminala, narzędzi do rozwoju zdalnego, interaktywnej automatyzacji oraz agentów do programowania AI, które coraz częściej działają bezpośrednio w shellu.
Zgodność z Node.js i Next.js
Zmiana o największym wpływie może dotyczyć kompatybilności, a nie jakiejś nowej API. W tym wydaniu dodano 1 517 testów dla Node.js oraz zgłoszono ulepszenia w modułach takich jak http, fs, stream, cluster, timers, zlib i vm. Wskazano również na lepsze wsparcie w kilku kategoriach: frameworki (Next.js 16, Nuxt, Fastify), narzędzia testowe (Vitest, Playwright, Testcontainers), rozwiązania z zakresu obserwowalności (OpenTelemetry oraz dd-trace od Datadog) oraz klienty do obsługi danych lub infrastruktury (TypeORM, RabbitMQ i AWS S3).
Flaga --bun zmusza interfejs wiersza poleceń narzędzia do działania pod Bun zamiast pod binarem Node.js wskazanym w jej shebangu. Zgodnie z informacjami z tego wydania rozwiązanie to działa z Next.js 16.3, Turbopackiem oraz React Compilerem:
bun --bun next build
Przyjęcie tego rozwiązania zależy ostatecznie od tego, czy istniejące aplikacje przetrwają zmianę, dlatego udane skompilowanie własnego projektu jest cenniejsze niż jakiekolwiek opublikowane wyniki testów.
Twierdzenia dotyczące wydajności w kontekście
Wyniki testów Bun dla wersji 1.4 pokazują nawet pięciokrotnie niższe zużycie CPU w stanie spoczynku, znacznie mniejsze zużycie pamięci w obciążeniach HTTP oraz szybszy start na Linux i Windows. Są to dane dostarczone przez producenta, więc należy je traktować jako orientacyjne. Niższe zużycie CPU, pamięci i czas startu mogą przekładać się na tańsze i bardziej responsywne usługi, ale tylko własne obciążenia mogą to potwierdzić. Aby uzyskać szerszy obraz kompromisów związanych z czasem działania, zapoznaj się z naszym porównaniem Node.js, Deno i Bun.
Niskorozrywkowy sposób oceny Bun 1.4
Przenoszenie całego systemu produkcyjnego rzadko jest mądre. Lepsze efekty dają małe, odwracalne eksperymenty.
Rozpocznij nowe API
Stwórz szkielet projektu i zbuduj małą usługę za pomocą Bun.serve:
bun init
Zastąp jeden proces przetwarzania obrazów
Przenieś pojedynczą ścieżkę przetwarzania z sharp do Bun.Image i porównaj jakość wyników oraz czas ich przetwarzania.
Przenieś jedno zadań zaplanowanych
Wybierz prosty zapis cron i zaimplementuj go ponownie za pomocą Bun.cron().
Zparalizuj swoje testy
Uruchom istniejący zestaw testów równolegle i zwróć uwagę na te, które przestają działać z powodu wspólnego stanu:
bun test --parallel
Oczyszczaj zależności
Wypróbuj polecenia dotyczące bezpieczeństwa i usuwania duplikatów na gałęzi i przejrzyj różnice:
bun audit fix
bun dedupe
Zbuduj swoją aplikację Next.js przy użyciu Bun
Zainstaluj wersję produkcyjną przy użyciu środowiska Bun i porównaj ją z obecnym procesem budowania:
bun --bun next build
We wszystkich przypadkach warto zmierzyć rzeczywiste wyniki zamiast polegać na publikowanych benchmarkach.
Trend konsolidacji
Bun 1.4 to nie tyle lista nowych interfejsów API, ile środowisko wykonawcze, które przejmuje funkcje wcześniej realizowane przez oddzielne pakiety. Ogólny układ składa się z warstwy środowiska wykonawczego zawierającego interfejsy Node.js, warstwy narzędziowej obejmującej testy, skrypty, aspekty bezpieczeństwa, procesy CI oraz terminale, oraz warstwy bibliotekowej dedykowanej obrazom, Markdown, przeglądarcom i mechanizmom cron:
Bun 1.4
│
┌─────────┼──────────┐
│ │ │
Runtime Tooling Libraries
│ │ │
Node.js Testing Image
APIs Scripts Markdown
Security Browser
CI Cron
Terminal
Ekosystem npm czerpie swoją siłę z łączenia tysięcy małych pakietów, ale ta siła wiąże się z kosztami w postaci zależności, konfiguracji, pracy nad kompatybilnością, aktualizacji bezpieczeństwa oraz rozbudowanych narzędzi. Bun stawia na coś przeciwnego: dostarcza przydatne elementy wewnątrz samego środowiska wykonawczego.
Główne wnioski
- Pytanie, które warto zadać, zmieniło się z „Czy Bun jest szybszy od Node.js?” na „Które elementy mojego stacku mogą zostać zastąpione przez Bun?”
- Budowane wewnętrznie funkcje zmniejszają zależności od języka docelowego, ale sprawdź równoważność funkcjonalną przed zastąpieniem dojrzałych bibliotek takich jak
sharpczy Playwright. - Sanituj wyjściowy tekst HTML generowany przez
Bun.markdown, gdy dane wejściowe nie są wiarygodne. - Skrypty i testy wykonywane równolegle dają szybkie korzyści, ale ujawniają problemy związane z kolejnością wykonywania operacji i wspólnym stanem.
- Traktuj benchmarki dostawców jako hipotezy i waliduj każdą funkcję w kontekście własnych obciążeń przed zatwierdzeniem jej użycia.
Literatura pokrewna
- Cechy Node.js 26, które cicho zastępują lata workaroundów — Przewodnik po API Temporal w Node.js 26, natywnym wykonywaniu TypeScript, narzędziach do zarządzania pamięcią cache oraz innych ulepszeniach, które eliminują długo istniejące rozwiązania tymczasowe.
- Co właściwie robi i nie robi natywna podpora Node.js dla TypeScript — Ten artykuł wyjaśnia, w jaki sposób Node.js uruchamia pliki .ts w sposób natywny poprzez usuwanie informacji typów, dlaczego pomija sprawdzanie typów oraz kiedy nadal potrzebny jest prawdziwy krok budowania.