Хотя стандарты инструментов начали стабилизироваться в области JavaScript, все еще существует некоторая путаница в отношении того, какой инструмент для работы. Это несколько подробное сравнение Rollup и Webpack. Начнем со сравнения соответствующих файлов конфигурации.

Конфигурация

rollup.config.js

webpack.config.js

Обратите внимание на различия:

В Rollup есть полифилы узлов для импорта / экспорта, тогда как в webpack нет

Rollup поддерживает относительные пути, тогда как webpack - нет, поэтому мы либо используем path.resolve, либо path.join.

Rollup требует, чтобы в пресетах es2015 для модулей было установлено значение false, потому что он будет обрабатывать модули как ES2015, если это возможно, и выполнять магию подъема области действия перед транспиляцией модуля.

Возьмем очень простой пример:

some-file.js

index.js

Что вы ожидаете от этого результата?

Возможно, именно здесь Rollup сияет. Для более простых модулей он возвращает очень эффективно преобразованный минимальный комплект, тогда как Webpack содержит много волшебства ™, включенного в комплект.

bundle.rollup.js - ~ 245 байт

bundle.webpack.js - ~ 4108 байт

В пакете Webpack фактический импорт происходит примерно на строке ~ 100. Если вы перейдете к этому пункту, вы увидите, что фактический код модуля в основном такой же (см. Ниже), с самой большой разницей в том, что в пакете Webpack каждый модуль заключен в функцию, которая может быть вызванным изнутри. Вот почему пакеты Webpack считаются «более безопасными» для больших / более сложных приложений.

Большая часть беспорядка устранена в сборках в производственном режиме и размере пакета.

Итак, как определить, какой из них вам подходит? В новейшей истории расхожее мнение было следующим:

«Используйте веб-пакет для приложений и накопительный пакет для библиотек»

Однако, как правило, оправдать это становится все труднее. Усовершенствования Webpack действительно выровняли игровое поле с точки зрения общей эффективности объединения, и Rollup недавно добавил разделение кода (основные недостающие функции между ними).

Чтобы провести параллель с реальной жизнью, я бы сравнил эту битву сборщиков с теорией дизайна продукта, называемой «моделью Кано». Модель Кано по существу утверждает, что «со временем восхитительные инновации становятся еще одной основной потребностью».

Возьмем, к примеру, стрелку на указателе уровня топлива автомобиля, чтобы указать, с какой стороны смотреть на топливный насос (рис. 1). Когда идея была задумана, это считалось большим нововведением, однако теперь это просто ожидание среди пользователей.

Чтобы увидеть настоящие отличительные черты, нам нужно вернуться на дикий запад 2016 года.

Накопительный пакет (около 2016 г.)

Плюсы:

  • Встряхивание дерева (включение живого кода / устранение мертвого кода)
  • esnext: основная запись в package.json для импорта es2015 + (переименована в «модуль»)
  • Подъем прицела
  • Простой API

Минусы:

  • Ограниченная поддержка загрузки альтернативных типов файлов (CSS, изображения и т. Д.)
  • Без разделения кода

Webpack (около 2016 г.)

Плюсы:

  • Расширенная поддержка CSS / HTML / загрузки изображений
  • Разделение кода
  • Замена горячего модуля для сверхбыстрых сборок разработчика

Минусы:

  • Нет тряски дерева
  • Нет прицела подъема
  • Нет встроенной поддержки модулей ES2015 +
  • Сложный API

С тех пор многое изменилось (приведенный выше список не является исчерпывающим, и у обеих библиотек есть дополнительные плюсы и минусы, которые я не мог перечислить), и обе библиотеки позаимствовали друг у друга реплики. Сообщество, окружающее обе библиотеки, также выросло, что помогло ускорить внедрение новых функций.

Rollup (сейчас) - Что изменилось?

  • Богатая экосистема плагинов для загрузки файлов / серверов разработки
  • Разделение кода (добавлено 8 февраля 2018 г. после двухлетнего ожидания! 🎉🎉)

Webpack (сейчас) - Что изменилось?

  • Встряхивание дерева и поддержка модуля ES2015 + (добавлено в Webpack 2)
  • Подъем прицела (добавлен в Webpack 3)
  • Поддержка esnext: main / module

На мой взгляд, вам все же, вероятно, следует предпочесть Rollup для библиотек, но вариант использования Rollup для больших приложений теперь намного более реалистичен. Одно можно сказать наверняка: и Webpack, и Rollup никуда не денутся. Я бы сказал, что основная причина стойкости этих двух библиотек - это потрясающие внутренние команды и бесконечные усилия, которые они прилагают для их поддержки и ответов на проблемы и вопросы StackOverflow.

Для более подробного сравнения внутреннего устройства двух библиотек Рич Харрис (создатель Rollup) сделал отличную запись здесь.

БОНУС: Приближается претендент

Parcel - это новый и интересный пакетировщик, который имеет многие из тех же функций, что и Rollup и Webpack (например, разделение кода и загрузка ресурсов), но главная особенность, которую он рекламирует, - это решение с нулевой конфигурацией для сборки пакетов. Если бы вы были в сообществе в 2015 году, вы бы помнили печально известную запись в блоге Усталость от JavaScript. Одно из замечаний автора заключается в том, что наши инструменты были просто беспорядком, и так оно и было. Мир еще не решил, какие инструменты мы должны использовать, поэтому большинство моих проектов представляли собой смесь Gulp, browserify (с babelify), и начать работу было нелегко.

С помощью Parcel преимуществом является то, что у вас есть файл index.html, который указывает на запись JavaScript, и вы можете просто запустить parcel index.html и сразу же запустить модный сервер разработки. Он также хвастается, что у него невероятно высокая скорость сборки (хотя в их сравнительной таблице отсутствует сравнение Rollup, поэтому я могу только предположить, что они похожи).

Если Parcel окажется таким же сильным, как Webpack / Rollup, я уверен, что многие из функций нулевой конфигурации всплывут на поверхность в этих библиотеках.