Hacker News Digest

Как устроен bun install

• Один бинарник — весь менеджер зависимостей живёт внутри Bun, нет внешних вызовов к npm, yarn, node-gyp.
• Сишный движок — парсинг package.json, yarn.lock, node_modules происходит на Zig, без JS-оверхеда.
• HTTP-пул + кэш — 50–100 параллельных потоков, кэш на диске + SQLite-индекс, повторный install — <100 мс.
• Symlink-ферма — модули не копируются, а hard-link’ются из глобального кэша; экономия 70 % диска.
• Муравьиный алгоритм — сначала скачиваются «листья» дерева зависимостей, потом родители; сеть греется максимально.
• Платформенные пакеты — если в lock-файле есть запись под Linux, macOS и Windows, скачиваются сразу три архива и раскладываются в node_modules/.cache, при запуске выбирается нужный.
• postinstall без shell — скрипты запускаются встроенным JS-движком, нет overhead’а на spawn bash/cmd.
• Проверка целостности — каждый tarball сверяется по SHA256 из lock-файла, кэш защищён от подмены.
• Мониторинг прогресса — терминал обновляется раз в 16 мс, рисуется ASCII-полоса и счётчик «пакетов/сек».
• Фоллбек к npm — если пакет не найден в официальном реестре, Bun автоматом лезет в npm и кладёт tarball в кэш, пользователь не замечает разницы.

• Пользователи обсуждают статью о внутреннем устройстве и производительности менеджера пакетов Bun.
• Многие хвалят скорость и простоту Bun, но отмечают проблемы совместимости с Node.js и стабильностью.
• Часть комментаторов сомневается в практической пользе высокой скорости установки пакетов и считает переход с Node.js рискованным.
• Упоминаются альтернативы — Deno, pnpm, npm — и сравнение с ними по скорости и надёжности.
• Некоторые считают, что Bun не предлагает «убийственных» фич, чтобы оправдать переход с зрелой экосистемы Node.js.

Пакетные менеджеры — зло

Пакетные менеджеры автоматизируют ад зависимостей: скачивают пакет → его зависимости → зависимости зависимостей… и ты в аду. Вручную хотя бы думаешь: «а надо ли?»

Большинство языков не знают, что такое «пакет», поэтому менеджер сам его придумывает. В итоге появляются «менеджеры менеджеров» (npm, yarn, pnpm…).

Языки с толстой стандартной библиотекой (Go, Odin) откладывают ад: 90 % задач решаются без сторонних пакетов.

Каждая зависимость — это долг: баги, security, поддержка. Мы взяли SDL2 — и год убили на чужие баги; проще написать своё, чем обновиться до SDL3.

Доверие к случайному коду из интернета — социальная болезнь программистов.

• Критика менеджеров пакетов сводится к тому, что они «автоматизируют ад зависимостей», скрывая от разработчика реальные издержки и риски.
• Автор предлагает вручную копировать и фиксировать нужные версии библиотек, чтобы осознанно контролировать, что именно попадает в проект.
• Оппоненты считают идею регрессом: ручное управление не масштабируется, тормозит разработку и не решает проблему транзитивных зависимостей.
• Поддержка Cargo, npm и прочих инструментов признаётся необходимой, но критикуется культура «микро-зависимостей» и отсутствие вендоринга.
• Компромисс видят в строгом вендоринге (Google), фиксации версий, feature-gates и использовании «batteries-included» стандартных библиотек (Go).