Таблица ловушек 2026:
Rspack и esbuild на удалённом Mac — холодный старт, инкрементальный кэш и воркеры
На удалённом Mac промахи с кэшем бандлера стоят минут CI и «зелёных» ложных проходов. Сопоставлены Rspack (webpack-граф и filesystem-кэш) и esbuild (параллелизм Go), даны каталоги и NODE_OPTIONS/GOMAXPROCS, завершает трёхшаговая приёмка. Вместе с кэшем Vite/Webpack, monorepo remote cache и памятью SSR-сборок выровняйте ключи задач.
01 Сценарий и базовые метрики
Крупный монорепозиторий на удалённом Mac: APFS, конкуренция с sshd и GUI, в CI — восстановление node_modules и кэшей. Разделяйте холодный старт и инкремент (второй production build на том же коммите с целым кэшем).
Фиксируйте четыре метрики: холодное и тёплое wall time, пик RSS, байты кэша; плюс SHA, хэш lockfile, node -v, версии Rspack и esbuild. Тяжёлый CSS-пайплайн сравнивайте с отдельным замером PostCSS, чтобы не списывать всё на бандлер. Боли: перегруз ядер lint+typecheck+bundle; битый кэш после смены ветки; кэш на сетевом диске вместо локального NVMe.
02 Rspack и esbuild: границы применимости
Rspack — для миграций с webpack, глубоких loaders и filesystem-кэша между перезапусками. esbuild — для узких транспиляций и однопроходной скорости без webpack-подобного дискового модульного кэша; гибрид: esbuild для пакетов, Rspack для приложения.
| Измерение | Предпочитайте Rspack | Предпочитайте esbuild |
|---|---|---|
| Глубина loaders и плагинов | Тяжёлые кастомные loaders, наследие asset-графа | В основном TS/JS, JSON, ограниченный набор плагинов |
| Цель персистенции | Долгоживущие workspace и восстановление кэша в CI | Короткие эфемерные шаги; скорость без многодневного кэша бандлера |
| Владелец эксплуатации | Команды, уже знакомые с webpack-конфигами | Команды, оптимизирующие поверхность настроек |
03 Холодный старт и инкремент: сравнение и исполняемые параметры
Матрица приёмки; пути подстройте под репозиторий. Один корень кэша на мажорную версию инструмента.
| Тема | Rspack | esbuild |
|---|---|---|
| Профиль холодного старта | Первый билд после сброса кэша; оплачиваются resolve и компиляция модулей | Часто самый быстрый холодный вариант среди связок на Node; на огромных деревьях входов остаётся дисковая связность |
| Профиль инкремента | Силён при cache: { type: 'filesystem' } и корректных ключах; опционально experiments.incremental для ускорения пересборок |
Выигрыш чаще от watch или от графа задач monorepo, а не от дискового модульного кэша webpack-типа |
| Типичный каталог кэша | node_modules/.cache/rspack или явный cache.cacheDirectory (например .rspack-cache в корне) |
Нет штатного персистентного модульного кэша; артефакты и remote cache — на уровне CI/Turborepo/Nx |
| Переключатель персистентного кэша | cache: { type: 'filesystem', buildDependencies: { config: [путь к rspack.config] } } |
На уровне ядра бандлера — нет; фиксируйте выходы задач и ключи оркестратора |
| Параллелизм и воркеры | Опция parallelism (наследие webpack) для ограничения одновременной обработки модулей |
export GOMAXPROCS=6 (пример) — потолок потоков Go; подберите ниже числа производительных ядер |
| Куча Node и пул потоков | NODE_OPTIONS=--max-old-space-size=8192; при нативных аддонах с тяжёлым fs — UV_THREADPOOL_SIZE=16 |
Куча Node не относится к самому esbuild; ограничивайте GOMAXPROCS, если оболочка на Node запускает несколько тяжёлых процессов |
export NODE_OPTIONS="--max-old-space-size=8192"
export UV_THREADPOOL_SIZE=16
export GOMAXPROCS=6
На восьми ядрах оставьте одно-два под macOS и SSH; при свопе сериализуйте тяжёлые шаги.
- Логируйте
cacheDirectoryв начале job; ключ CI — lockfile + хэш конфигов. - Кэш на NVMe раннера, не на сетевом томе без замеров; при Rspack+esbuild следите за суммарным RSS.
- После мажорного апдейта Rspack — контрольный холодный билд и сравнение размера кэша.
04 Диск и память на удалённом Mac: пороги
Кэш растёт с модулями и source map; на Mac оставляйте запас под ОС и сессии.
| Сигнал | Консервативный порог | Действие |
|---|---|---|
| Свободный диск после восстановления | Не менее 25 ГБ для среднего монорепо; 40 ГБ, если храните несколько поколений кэша | Очистите старые .rspack-cache; уберите дубликаты деревьев node_modules; сузьте ключи артефактов CI |
| Рост каталога кэша | Предупреждение при росте неделя к неделе > 20% без смены зависимостей | Инвалидация при смене хэша конфигурации; аудит source map и копирования статики |
| Пик RSS при сборке | Держаться ниже грубо RAM − 8 ГБ на общих хостах 24–36 ГБ | Снизить parallelism и GOMAXPROCS, шардировать пакеты или разнести job |
| Давление на своп | Устойчивый своп > 2 ГБ во время компиляции | Запускать Rspack и esbuild последовательно; уменьшить одновременные тяжёлые стадии |
df -h до job.05 Три шага приёмки перед релизом и FAQ
Шаг 1: с чистого кэша на релизном SHA — один production build и лог; регрессия холода >15% без крупных апдейтов зависимостей — стоп и diff конфигов.
Шаг 2: сразу второй билд должен ускориться (ориентир 25–40% к холоду для Rspack с filesystem-кэшем); иначе путь кэша, ключи или сканирование диска.
Шаг 3: при capped GOMAXPROCS и Node SSH должна оставаться отзывчивой; затем только промоут артефакта.
В: Один job для Rspack+esbuild?
О: При высоком RSS — сериализация или шардирование пакетов.
В: Turbo и Rspack?
О: Turbo — выходы задач; Rspack — модульный граф внутри задачи; оба ключа с lockfile и конфигом.
В: Кэш по веткам?
О: Разделяйте при смене алиасов и globs workspace.
Выбирайте Rspack, когда нужны глубина webpack-графа и filesystem-кэш, восстанавлиемый в CI; выбирайте esbuild для узких высокоскоростных шагов, принимая стратегию кэша на уровне оркестратора. Измеряйте холод и тёплый прогон, берегите головной диск и ОЗУ на удалённом Mac и выкладывайте только после трёхшаговой приёмки.
Главная, тарифы, помощь, блог фронтенда. Покупка и бронь — выделенный NVMe под холодные сборки.