2026: выбор рантайма для фронтенда на удалённом Mac:
Bun, Node.js 24 и Deno — установка, lockfile, зеркала и кэш

Узлы Apple Silicon в аренде часто ближе к VPN или региону CI, но остаются общими: холодный кэш, конкурирующие сборки и разная загрузка диска меняют фактическое время install. Любой заголовок «в три раза быстрее» условен: нужны стабильный путь к зеркалу registry, тёплый или холодный node_modules и отсутствие параллельных тяжёлых задач. Для фронтенд-инженерии важнее воспроизводимость, чем пиковая скорость: закрепите мажор Node 24 / линию Bun / версию Deno, храните один канонический lockfile и документируйте endpoint registry так же, как версию Node.

Сравнивайте честно: удалите node_modules и соответствующие кэши, снимите лишнюю нагрузку с CPU, сделайте несколько прогонов и фиксируйте хост зеркала и хэш lockfile рядом с замером. На корпоративных сетях учитывайте TLS-инспекцию: без доверенного корневого сертификата Bun и npm могут вести себя по-разному.

Для monorepo и удалённого кэша Turborepo дополните этот материал гайдом pnpm, Turborepo и зеркала registry на удалённом Mac. Для раскладки Node по проектам — изоляция версий Node и npm; типичные ловушки — чек-лист Node/npm и Safari.

Строки отражают типичные задачи веб-фронтенда в 2026 году, а не исчерпывающий список edge case. Перед сменой рантайма прогоните свои package.json scripts и нативные зависимости (postinstall, бинарники платформы).

Шаг 1 — Закрепить рантайм и lockfile. В репозитории должен быть ровно один «истинный» lockfile на выбранный менеджер пакетов. На удалённом Mac перед install активируйте ту же мажорную линию, что и в CI: Node 24, согласованный релиз Bun или зафиксированный Deno. Расхождение здесь съедает любой выигрыш по скорости и ломает детерминизм фронтенд-сборки.

Шаг 2 — Зеркало registry и каталоги кэша. Выносите URL зеркала и корни кэша в профили shell или секреты пайплайна, а не в «только на ноутбуке» .npmrc. Для pnpm согласуйте store-dir с чек-листом monorepo. Для Bun на прокси с подменой сертификата добавьте доверенные корни в систему или окружение, иначе install будет флапать.

Шаг 3 — Паритет сборки. Запускайте тот же production build, что и в CI; один раз на релизный «поезд» сравните вывод Vite (или размер бандла) между локальной машиной и удалённым Mac. Детали по кэшу — оптимизация кэша Vite/Webpack; проверка перед выкладкой — деплой и Safari в три шага.

Vite нередко запускают под не-Node рантаймами, но плагины, порождающие процессы или тянущие бинарники, всё ещё исходят из мира Node; адаптеры SSR ломаются первыми. Практичная политика: релизные сборки стандартизировать на Node 24, Bun подключать в отдельной ветке после зелёных postinstall и E2E, Deno оставлять репозиториям с центральным deno.json. Не смешивайте PATH «тихо» между сессиями на одном арендованном Mac — это источник «у меня работает».

Выполняйте на общем удалённом Mac только с согласия владельца или администратора. Команды разрушительны для локальных кэшей и части артефактов сборки.

A. Изоляция рантайма по проектам

# Node: fnm или nvm — пример с fnm
fnm install 24
fnm use 24
node -v

# Bun: закрепите версию в пользовательском префиксе
curl -fsSL https://bun.sh/install | bash
~/.bun/bin/bun --version

# Deno: версионируемая установка
curl -fsSL https://deno.land/install.sh | sh
deno --version

# В каждом репо избегайте смешанных глобальных префиксов
npm config delete prefix 2>/dev/null || true
pnpm config get store-dir

B. Освободить диск: npm / pnpm / Yarn

npm cache verify
npm cache clean --force
pnpm store prune
yarn cache clean

# Артефакты проекта (из корня репозитория)
rm -rf node_modules .vite dist build .turbo .next .nuxt

C. Кэши Bun и Deno

rm -rf ~/.bun/install/cache 2>/dev/null || true
# Опционально: deno cache --reload для конкретного entry
rm -rf ~/Library/Caches/deno 2>/dev/null || true

Переустановите зависимости с тем же зеркалом и lockfile; для проверки графа используйте pnpm install --frozen-lockfile или эквивалент npm/yarn.