Bun 1.4 Вбудовані інструменти, які можуть замінити Sharp, Puppeteer, node-pty та інші

Типовий проект на JavaScript накопичує залежності для кожної функціональності, яка йому потрібна: sharp для обробки зображень, парсер Markdown, Playwright або Puppeteer для автоматизації браузера, бібліотеку cron, node-pty для псевдотерміналів, concurrently або npm-run-all для паралельного виконання скриптів, а також низку налаштувань CI для прискорення тестування. Bun 1.4 обирає інший підхід: багато з цих функцій можуть реалізовуватися безпосередньо в момент виконання. У цьому посібнику розглядаються нові вбудовані інструменти разом із фрагментами коду, необхідними для їх випробування, а також пропонується спосіб їх оцінки з мінімальним ризиком.

Згідно з оголошенням про випуск, Bun 1.4 було розіслано 20 серпня 2026 року — у нього додано понад 1 500 тестів сумісності з Node.js, виправлено понад 2 900 проблем та скорочено використання CPU та пам’яті у неактивному стані. API цієї нової версії все ще можуть змінюватися, тому сприймайте наведену нижче інформацію як моментальний знімок та підтверджуйте її, порівнюючи з офіційним оголошенням про Bun 1.4 та поточною документацією. Основна ідея цього випуску — не стільки підвищення базової швидкості, скільки скорочення обсягу інструментарію.

Встановлення чи оновлення

Bun можна встановити за допомогою скрипта терміналу, npm, Homebrew, PowerShell у Windows або у вигляді образу Docker. Кожен позначений нижче рядок — це один із варіантів; оберіть той, який підходить вашому середовищу:

--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

Якщо Bun вже є на вашому комп’ютері, один командний запит переведе вас на останню версію:

bun upgrade

Обробка зображень за допомогою Bun.Image

Bun.Image дозволяє виконувати розшифрування, зміну розміру, обертання та кодування зображень у поширених форматах прямо під час виконання, тож вам більше не потрібна залежність від нативних бібліотек з обробки зображень. Наведена нижче послідовність операцій читає JPEG, вміщує його у прямокутник розміром 1024 на 1024, зберігаючи співвідношення сторін, обертає його, кодує у форматі WebP з якістю 85 та зберігає результат:

await Bun.file("photo.jpg")
  .image()
  .resize(1024, 1024, { fit: "inside" })
  .rotate(90)
  .webp({ quality: 85 })
  .write("thumb.webp");

Оскільки кожен крок повертає той самий об’єкт для подальших операцій, ця послідовність працює зверху вниз, як рецепт. Типові сфери застосування включають створення мініатюр для завантаження, зміну розміру аватарок, конвертацію JPEG у WebP, використання API для роботи з зображеннями та оптимізацію файлів перед їх збереженням.

Bun повідомляє, що його реалізація перевершує sharp у кількох власних тестах продуктивності, зокрема під час зміни розміру та кодування PNG у форматі 1080p. Ще однією значною перевагою є видалення нативного модуля, який часто ускладнює процес будови Docker-образів та роботу кешів CI. Якщо ви залежите від розширених функцій sharp, переконайтеся, що операції, які ви використовуєте, справді існують, перш ніж змінювати рішення.

Автоматизація безголового браузера за допомогою Bun.WebView

Bun.WebView — це вбудований API безголового браузера, який дозволяє навігувати, клікати, прокручувати, виконувати JavaScript та створювати скріншоти. Зверніть увагу на оголошення await using: воно пов’язує термін життя браузера з контекстом, у якому він використовується, тож браузер автоматично звільняється після завершення блоку, навіть у разі виникнення помилок.

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()
);

Скрипт відкриває сторінку, переходить за посиланням, читає назву документа та зберігає скріншот. Це дозволяє виконувати багато дрібних завдань без необхідності використання повноцінної автоматизаційної платформи: сервісів для створення скріншотів, тестів на працездатність, інструментів для збору даних з веб-сторінок, перевірки часу роботи, інструментів для перевірки посилань та простих процесів контролю якості. Коли потрібен більш глибокий контроль, Bun.WebView надає можливість використання протоколу Chrome DevTools. Для великих комплексних систем із потребою у роботі з різними браузерами, ймовірно, краще використовувати спеціалізований інструмент.

Рендеринг Markdown за допомогою Bun.markdown

Bun.markdown перетворює Markdown у кілька форматів. Найпростіший варіант повертає рядок HTML:

const html = Bun.markdown.html(
  "# Hello **world**"
);

Він також може безпосередньо створювати елементи React, що зручно, коли компонент відображає сторінку README чи документацію:

export default function Page() {
  return Bun.markdown.react(readme);
}

Рендеринг можна далі налаштувати, наприклад для форматування вихідних даних у терміналі. Підтримуються розширення Markdown у стилі GitHub, такі як таблиці, списки завдань, підчеркування та автопосилання. Це підходить для сайтів документації, порталів розробників, блогів, проглядачів README, допомоги CLI, баз знань та інтерфейсів, які відображають Markdown, створений моделями.

Є одна важлива застереження, яка має більше значення, ніж усі інші: HTML-вихідні дані не пройшли обробку. Будь-який Markdown від користувачів, сторонніх організацій чи LLM мусить пройти процедуру очищення перед тим, як потрапити до браузера, інакше існує ризик вставки скриптів.

Заплановані завдання за допомогою Bun.cron

Bun.cron() працює у двох режимах. У першому він реєструє завдання у планувальнику операційної системи: crontab у Linux, launchd у macOS та Task Scheduler у Windows. Функція приймає шлях до скрипту, вираз cron та назву завдання; це завдання запускає працівника щопонеділка о 02:30:

await Bun.cron(
  "./worker.ts",
  "30 2 * * MON",
  "weekly-report"
);

Оскільки плануванням керує операційна система, завдання виконується навіть тоді, коли процес Bun не активний. У другому режимі планування знаходиться всередині активного процесу, тут воно запускається кожні п’ять хвилин. Оголошення using зупиняє завдання після закінчення його області видимості:

using job = Bun.cron(
  "*/5 * * * *",
  async () => {
    await cleanupTempFiles();
  }
);

Виконання завдань ніколи не перекривається, і підтримуються явні часові зони. Хорошими кандидатами є працівники з очищення даних, створення звітів, технічне обслуговування баз даних, синхронізація даних, обробка електронних листів пакетами та періодичне звернення за даними. Пам’ятайте, що завдання всередині процесу зникають після його перезапуску, і якщо ви запускаєте кілька копій, кожна з них буде виконуватися окремо, якщо тільки ви не додасте механізм координації.

Виконання скриптів паралельно

bun run --parallel замінює concurrently та npm-run-all. Передайте кілька імен скриптів, щоб виконати їх одночасно:

bun run --parallel build test

Шаблони типу glob вибирають групу скриптів:

bun run --parallel "build:*"

У поєднанні з --filter цей же флаг дозволяє виконувати скрипт у кожному робочому просторі:

bun run --parallel --filter '*' build

Зазвичай одна помилка зупиняє все; --no-exit-on-error дозволяє решті завдань завершитися, що корисно для одночасного збирання всіх помилок тестів:

bun run --parallel --no-exit-on-error --filter '*' test

Кожен рядок виводу починається з позначки скрипту, який його створив, тому змішані журнали залишаються читабельними. У монорепозиторії це дозволяє замінити послідовну обробку на розподілену між ядрами процесора:

package A → build
package B → build
package C → build

Паралельні виконання не розуміють залежностей між пакетами, тому якщо один пакет має бути скомпільований перед іншим, все одно потрібен певний порядок або засіб керування завданнями, який би моделював ці залежності.

Швидше виконання тестів

bun test отримує прапорець --parallel:

bun test --parallel

Ви можете явно встановити кількість робочих процесів:

bun test --parallel=4

Файли передаються робочим процесам динамічно, а не розділяються заздалегідь на фіксовані групи, тож один повільний файл не залишає інші процеси без роботи. Три пов’язані прапорці призначені для CI. Метод шардування розподіляє набір тестів між машинами; тут показано перший з трьох шматків:

bun test --shard=1/3

Виконання лише тестів, які постраждали від ваших змін, скорочує час обробки локальних повідомлень:

bun test --changed

Фіксування тривалості виконання дозволяє під час подальших запусків збалансувати навантаження за допомогою реальних даних про час:

bun test --timings=timings.json

Паралельне виконання розкриває тести, які ділять стан, наприклад спільну базу даних, фіксовані порти чи тимчасові файли. Очікуйте необхідності виправлення деяких проблем із ізоляцією під час першого увімкнення цього режиму.

Виправлення вразливих залежностей

Для підтримки безпеки існує вбудована команда:

bun audit fix

Вона оновлює вразливі пакети до виправлених версій та встановлює їх. Якщо для виправлення потрібне підвищення до нової основної версії, Bun повідомляє про це замість того, щоб застосувати оновлення; додайте --latest, щоб це увімкнути. Розглядайте такі значні оновлення як будь-які зміни, що можуть порушити функціонал. У середовищі CI безпека залежностей інтегрується у звичайний крок встановлення.

Видалення дублікатів залежностей

У великих проектах часто існує кілька майже ідентичних версій одного пакета:

esbuild@0.15.10
esbuild@0.15.11

Коли одна версія відповідає усім вимогам, ця команда об’єднує дублікати:

bun dedupe

Якщо дублікати залишаються, перевірка завершується помилкою, що робить її ідеальним етапом у процесі CI:

bun dedupe --check

Кількість дублікатів, що зменшується, означає менші дерева залежностей, швидше встановлення, менше використання диска, простіше обслуговування та потенційно менші розгортання.

Керування інтерактивними програмами за допомогою Bun.Terminal

Bun.Terminal — це вбудований псевдотермінал, який дозволяє JavaScript керувати інтерактивними програмами без використання node-pty:

bash
vim
htop

Псевдотермінал має велике значення, оскільки такі програми поводяться по-різному, коли виявляють справжній термінал: вони створюють інтерфейси, які заповнюють увесь екран, використовують кольори та очікують натискання клавіш. Це робить Bun.Terminal корисним для інструментів розробників, CLI-засобів, панелей керування терміналом, інструментів віддаленої розробки, інтерактивної автоматизації та агентів для кодування з ШІ, які все частіше працюють безпосередньо в шеллі.

Сумісність з Node.js та Next.js

Зміна з найбільшим впливом може стосуватися сумісності, а не якоїсь нової API. У цьому випуску додано 1 517 тестів для Node.js, а також повідомляється про покращення в модулях http, fs, stream, cluster, timers, zlib та vm. Також зазначено кращу підтримку в кількох категоріях: фреймворки (Next.js 16, Nuxt, Fastify), інструменти тестування (Vitest, Playwright, Testcontainers), системи моніторингу (OpenTelemetry та dd-trace від Datadog) та клієнти для роботи з даними чи інфраструктурою (TypeORM, RabbitMQ та AWS S3).

Прапорець --bun змушує CLI інструменту працювати під керуванням Bun замість бінарника Node.js, вказаного у її shebang. Згідно з описом випуску, це працює з Next.js 16.3, Turbopack та React Compiler:

bun --bun next build

Прийняття цього рішення в кінцевому підсумку залежить від того, чи зможе ваша існуюча програма працювати після переходу, тому успішна компіляція власного проекту має більшу цінність, ніж будь-які опубліковані тестування.

Твердження щодо продуктивності в контексті

Результати тестування Bun версії 1.4 показують у п’ять разів нижчу активність CPU у режимі очікування, значно менше використання пам’яті у завданнях HTTP та швидший старт на Linux та Windows. Це дані, надані виробником, тому їх слід розглядати як орієнтовні. Нижча активність CPU, використання пам’яті та час старту можуть призвести до дешевших та більш швидких у використанні сервісів, але лише ваші власні завдання можуть це підтвердити. Щоб дізнатися більше про компроміси під час роботи програми, перегляньте нашу порівняння Node.js, Deno та Bun.

Безризиковий спосіб оцінки Bun 1.4

Повне переміщення виробничої системи рідко є розумним рішенням. Краще використовувати невеликі, зворотні експерименти.

Розпочніть новий API

Створіть основу проекту та розробіть невеликий сервіс за допомогою Bun.serve:

bun init

Замініть один процес обробки зображень

Перенесіть одну конвеєрну схему sharp у Bun.Image та порівняйте якість результату та час виконання.

Перемістіть одне заплановане завдання

Виберіть просту задачу cron та перереалізуйте її за допомогою Bun.cron().

Паралелізуйте свої тести

Запустіть існуючий набір тестів паралельно та визначте, які з них не працюють через спільний стан:

bun test --parallel

Очистіть залежності

Спробуйте команди забезпечення безпеки та усунення дублікатів на гілці та перегляньте різницю:

bun audit fix
bun dedupe

Створіть свій додаток Next.js під керуванням Bun

Запустіть версію для продакшну за допомогою середовища Bun та порівняйте її з вашою поточною схемою обробки:

bun --bun next build

У кожному випадку вимірюйте результати, а не покладайтесь на оприлюднені тестові дані.

Тренд консолідації

Bun 1.4 — це не стільки список нових API, скільки одне середовище виконання, яке бере на себе функції, що раніше належали окремим пакетам. Основна структура складається зі шару середовища виконання з API Node.js, інструментального шару, який охоплює тести, скрипти, питання безпеки, CI та термінали, а також бібліотечного шару для роботи з зображеннями, Markdown, браузерами та cron:

Bun 1.4
               │
     ┌─────────┼──────────┐
     │         │          │
 Runtime    Tooling    Libraries
     │         │          │
 Node.js     Testing    Image
 APIs        Scripts    Markdown
             Security   Browser
             CI         Cron
             Terminal

Екосистема npm отримала свою потужність завдяки поєднанню тисяч невеликих пакетів, але ця потужність має свою ціну у вигляді залежностей, налаштувань, роботи з сумісністю, оновлень безпеки та фрагментованих інструментів. Bun робить ставку на протилежне: вбудовує корисні базові елементи безпосередньо в середовище виконання.

Основні висновки

• Питання, яке варто поставити, змінилося з «Чи Bun швидший за Node.js?» на «Які компоненти моєї стек-технології може замінити Bun?»
• Вбудовані інструменти зменшують кількість залежностей від нативних бібліотек, але перевіряйте рівні функціональності перед заміною вже перевірених бібліотек, таких як sharp чи Playwright.
• Санітуйте HTML-вихідний код, створений за допомогою Bun.markdown, щоразу, коли вхідні дані є ненадійними.
• Паралельне виконання скриптів та тестів — це швидкий спосіб покращення продуктивності, але воно може виявити приховані проблеми з порядком виконання та спільним станом даних.
• Ставтеся до тестів продуктивності від постачальників як до гіпотези та перевіряйте кожну функцію у контексті власних навантажень перед її впровадженням.