Сборщик это компилятор интерфейса: он берёт разбросанные по папкам модули, разворачивает импорты, встряхивает неиспользуемое, минифицирует результат и выдаёт файлы, которые браузер тянет по сети. Стандартов сборки целая волна, и пара ветеранов, Rollup и Parcel, олицетворяют два подхода к одному делу: явная конфигурация с точным контролем против нулевой конфигурации из коробки. Выбор между ними это выбор философии команды, и он определяет ежедневную рутину разработки сильнее, чем кажется по описаниям.
Ниже оба разобраны честно: что делает сборщик вообще, чем Rollup хорош для библиотек и фронтендов с ручным контролем, чем Parcel берёт с первого дня, как устроена скорость у обоих, что делать с форматами вывода под старые рантаймы, как резать бандл на чанки и как выбирать под конкретный проект без бессмысленных споров.
Зачем коду сборщик и что он делает между исходником и продакшеном
Сырой исходник современной страницы это сотни модулей, десятки зависимостей и россыпь языков поверх JavaScript: типы, разметка, стили. Браузер в теории умеет модули, на практике сеть не любит сотни мелких файлов, а легаси-парк требует собранных кусков, и сборщик закрывает разрыв между культурой разработки и требованиями передачи. Он же наводит порядок: неиспользуемый код вылетает, имена сжимаются, мёртвые ветки исчезают.
Вторая обязанность это переводы: новые версии языка в старые синтаксисы, типы и разметка в план JavaScript, стили в критические куски и файлы, и всё это по карт целей, где указано, какие браузеры обязаны получить работающий код. Третья обязанность это наблюдаемость: карты источников возвращают стеки ошибок из минифицированного продакшена в читаемый исходник, и без них отладка превращается в археологию.
Четвёртая обязанность это экономика передачи: бандл режется на куски по мере надобности, тяжёлые редкие экраны грузятся по требованию, общий код выносится в разделяемые чанки, и первый экран получает минимум байтов. Сборщик стал диспетчером трафика, и выбор его влияет на метрики скорости заметнее, чем любая отдельная оптимизация кода.
Пятая обязанность это конвейер разработки: локальный сервер, мгновенная подмена модулей после правки и перезагрузка состояния без потери страницы. Скорость внутреннего цикла решает темп команды, и современные инструменты соревнуются в этом месте громче всего, потому что секунды между сохранением и результатом умножаются на тысячи сохранений в месяц.
Rollup упругий ES модульный каркас с глубоким tree shaking
Rollup родился из идеи, что сборка должна опираться на стандарт модулей, и результат обязан выглядеть как написанный вручную код: плоский, читаемый, без обёрток на каждый модуль. Встряхивание неиспользуемого здесь было поставлено на недосягаемую глубину, потому что статический анализ импортов по стандарту даёт точные сведения о том, что действительно используется, и библиотеки, собранные Rollup, годами оставались эталоном компактности.
export default {
input: "src/index.js",
output: {
file: "dist/bundle.js",
format: "es",
sourcemap: true
},
plugins: [resolve(), terser()]
};Конфигурация это контракт, который читается как документация проекта: входы, плагины, карты целей, форматы вывода, внешние зависимости. Такой контроль стоит рутины: каждый новый тип файлов это плагин, каждая хитрая потребность это строчка конфигурации, и команда платит эту цену осознанностью каждого шага сборки.
Экосистема плагинов выросла вместе с инструментом: разметка, стили, типы, копирование ассетов, замеры размеров, и зрелые цепочки переходят от проекта к проекту как знакомый чемодан. Экосистема Vite исторически опиралась на Rollup для продакшен-сборки, и это породило поколение плагинов, совместимых с обоими мирами, что смягчило цену входа.
Слабая сторона ветерана это скорость из коробки на больших графах и живая переработка кода, где конкуренты годами показывали разрыв. Классические ответы известны: кэш инкрементальных сборок, вынос тяжёлых переводов на более быстрые инструменты и честный расчёт, что минута продакшен-сборки в конвейере стоит дешевле, чем минуты разработчика в цикле правки.
Parcel философия нулевой конфигурации и цена этого удобства
Parcel поставил во главу обещание: поставил и работает, без конфигурационного файла, без списка плагинов, без процедураа инициализации. Он сам распознаёт типы файлов, сам подбирает переводы, сам режет бандл на куски, и приложение с нуля собирается до рабочего состояния за минуты, что в своё время резко опустило порог входа в профессию.
Удобство это плата комфортом контроля: поведение по умолчанию покрывает массовые сценарии, но редкие потребности обнаруживаются внутри инструмента, и решение ищется в его устройстве, а не в явном конфиге. Зрелые команды знают обе стороны этой медали и выбирают Parcel там, где стандартное поведение совпадает с их желаниями, а не там, где они надеются его перенастроить завтра.
Кэш у Parcel первоклассный: инкрементальные сборки хранят результаты переводов и переживают перезапуски, и большие проекты пересобирают изменённое за секунды. Многопроцессорность добавляет скорости на свежих машинах, и в сценарии приложения с рутинными правками Parcel долгие годы держал репутацию самого быстрого из простых.
Слабая сторона это экосистема: расширения существуют, но написание своих требует погружения в устройство инструмента, и сообщество тоньше, чем у ветерана с явными плагинами. Для продуктовых команд это означает больше доверия дефолтам и меньше права на экзотику, и это честная сделка для проектов внутри мейнстрима.
Скорость и кэш как оба решают самую скучную часть работы
Скорость сборки это три разные скорости, и путать их стоит дорого. Скорость первого запуска важна новому человеку и конвейеру без кэша, скорость инкрементальной пересборки важна циклу правки, скорость холодного старта после обновления зависимостей важна каждое утро. Оба инструмента отвечают на три вопроса кэшем, и различие в том, где хранится кэш и что его сбрасывает.
Инкрементальность выросла в главный фронт: пересборка одного изменённого модуля без обхода графа, сохранение переводов между запусками, распараллеливание независимых шагов. Parcel положил эту дисциплину в основу, Rollup догоняет плагинами и внешними ускорителями, и волна быстрых инструментов на других движках подняла планку для всех, заставив ветеранов шевелиться заметнее.
Замеры обязаны быть своими: тот же проект, те же зависимости, холодный и тёплый сценарии, и секунды записываются до выбора, а не после. Сравнения из чужих блогов вводят в заблуждение через иные графы зависимостей, и двадцать секунд разницы на чужом проекте превращаются в две на вашем и наоборот, честный замер дешевле честного мнения.
Скорость разработки важнее скорости продакшена, и обе важнее скорости GitHub-звёзд: локальный цикл правок обязан быть мгновенным у обоих, продакшен-сборка живёт в конвейере и может занимать минуты без ущерба продукту. Расстановка приоритетов по этим трём скоростям снимает половину споров о выборах инструментов ещё до их начала.
Форматы вывода библиотеки приложения и старые рантаймы
Вывод это цель сборки, и здесь различия ветеранов максимальны. Rollup умеет выпускать результат во всех смыслах слова: модульный формат для современных потребителей, общий формат для старых рантаймов, самодостаточный файл для подключения без сборки. Для библиотек это решающий набор, потому что библиотеку потребляют чужие сборщики, и чистый модульный вывод без обёрток становится витриной качества.
Parcel ориентирован на приложения: его вывод это чанки страницы с предсказуемыми именами и картами, и форматы под чужих потребителей не его жанр. Граница проходит ровно тут: библиотека и переиспользуемый пакет собираются инструментом с точным контролем вывода, приложение собирается инструментом с философией выдачи страницы.
Цели браузеров описываются списком поддержки, и оба инструмента уважают его переводами синтаксиса: старый парк получает развёрнутый код, свежие версии оставляются компактными. Библиотечный вывод дополнительно уважает внешние зависимости: тяжёлые соседи объявляются внешними и не попадают в бандл, потому что потребитель принесёт их сам, и это правило отличает библиотечную сборку от прикладной.
Карты источников обязательны в обоих жанрах: продакшен-минификация без карт лишает команду возможности читать ошибки, и флаг их генерации стоит по умолчанию, а не по праздникам. Проверка карт входит в релизный чек-лист после первой же бессонной ночи по чужому стеку без имён.
Код-сплиттинг динамические импорты и границы чанков
Резка бандла начинается с динамических импортов: редкий экран, тяжёлый редактор, график, конвертер запрашиваются в момент надобности, и сборщик оборачивает их в отдельные чанки. Первый экран худеет на вес удалённой редкости, а редкость приезжает по требованию за секунды сети.
const editor = await import("./heavy/editor.js");
editor.mount(container);Границы чанков назначаются по смыслу маршрутов: экран это чанк, крупная функция это чанк, и общий код между чанками выносится в разделяемые куски, чтобы не грузиться дважды. Оба инструмента делают это из коробки с разной степенью ручного контроля, и Rollup даёт явные правила границ, а Parcel решает автоматически, истина посередине: важные границы назначаются руками, остальное оставляется автомату.
Размер кусков контролируется бюджетом: лимит на стартовый чанк и на каждый кусок проверяется в конвейере, и рост свыше лимита останавливает слияние. Бюджет превращает размер из надежды в правило, и оба ветерана дружат с инструментами проверки размеров без процедураьных плясок.
Предзагрузка завершает картину: критичные чанки прогреваются в фоне после первого экрана, и переходы между разделами ощущаются мгновенными, хотя физика остаётся прежней. Сборщик это диспетчер, и хорошая логистика экономит больше, чем сами байты.
Динамические импорты в библиотеке живут своей жизнью: потребители ожидают единый вход, и внутренние ленивые куски оформляются как отдельные точки входа. Решение обсуждается до сборки, потому что переделка границ после публикации это смена контракта, а смена контракта в библиотечном мире это версия с миграцией для всех.
Выбор под проект приложение библиотека или гибрид без догм
Выбор сводится к трём вопросам. Что собираем: библиотека или пакет для чужих потребителей требует управляемого вывода и берёт Rollup, приложение требует скорости старта и повседневного удобства и долгие годы брало Parcel. Кто собирает: команда с знанием цепочек и потребностью в контроле живёт в конфигурации, команда без выделенного фронтенд-мастера живёт в дефолтах. Что вокруг: экосистема инструментов вокруг проекта уже выбрала свои сборки, и совместимость с её плагинами экономит недели.
Волна новых инструментов на других движках изменила расклад в обоих лагерях, и ответ 2020-х годов звучит как третьи варианты для новых приложений, но ветераны никуда не делись: Rollup остался эталоном вывода библиотек и основой чужих цепочек, Parcel остался самым коротким путём от папки до работающего сайта. Зрелый выбор признаёт эту географию вместо поиска единственно верного ответа на все проекты.
Порядок выбора и внедрения свёрнут в короткую лестницу:
- определить жанр вывода: библиотека, приложение или гибрид;
- замерить оба варианта на своём графе зависимостей холодным и тёплым сценарием;
- составить список обязательных потребностей: форматы, плагины, границы чанков;
- выбрать по совпадению дефолтов с потребностями, а не по чужим рейтингам;
- зафиксировать бюджеты размеров и проверку карт источников в конвейере;
- назначить границы чанков по маршрутам и вынести общий код;
- пересматривать выбор раз в год вместе с обновлением экосистемы.
Сборщик это инструмент на годы, и разница между ним и соседним инструментом и различие живёт в рутине, а не в заголовках сравнений. Команда, которая честно ответила на три вопроса выбора, получает скучную предсказуемую сборку, и именно скучность здесь и есть высшая оценка: про инструменты вспоминают только когда они ломаются, и лучший сборщик тот, о котором не вспоминают вовсе.