Зачем использовать модуль-упаковщик (webpack) для запуска задачи (grunt)?

Question

В прошлом я использовал генератор-генератор Grunt для всех моих задач dev. Обычно, когда я работаю над проектом, я буду использовать его с компасом для компиляции моего scss, а затем упаковать и угадать мой JS, оптимизировать изображения, перебрать код и многое другое.

Недавно я видел тенденцию к тому, что люди используют webpack вместо плагинов для ворчания для многих из этих задач. Почему это? Что лучше в модуле-модуле в этом отношении?

Answer 1

Я уверен, что у других есть свои причины, но самая главная причина, почему я мигрировал в WebPack (точнее webpack-dev-server), потому, что она serves your bundle from memory (в отличии от диска), а его наблюдатель будет recompile only the files you changed while reusing the rest from cache (в памяти). Это позволяет быстрее развиваться. Я имею в виду, что пока я активно редактирую код, я могу ctrl + s в Sublime Text, к тому времени, когда я переместил alt + tab в Chrome, это уже сделано для восстановления. Раньше у меня была грубая + браузерная + установка с использованием grunt-watch, и потребовалось не менее 5 секунд, чтобы перестраивать каждый раз, когда я сохраняю (то есть после того, как я создал кучу специализированных оптимизаций в сборке grunt). Это, как говорится, я все еще интегрировал webpack с глотком, поэтому у меня был руководитель задачи для моего проекта.

EDIT 1: Я также хочу добавить, что старый хрюканье + LESS/SASS + браузеруировать + uglify + настройку gunt-watch не очень хорошо масштабировались. Я работал над крупным проектом с нуля. Сначала это было прекрасно, но потом, когда проект рос, с каждым днем ​​все ухудшалось. В конце концов стало невероятно неприятно ждать, пока хрюканье закончит строительство каждого ctrl + s. Также стало очевидно, что я ждал кучу неизменных файлов.

Еще одна приятная вещь в том, что веб-пакет позволяет требовать таблицы стилей в .js, который устанавливает связь исходных файлов в одном модуле. Первоначально мы установили зависимости stylesheet, используя импорт в .less-файлах, но отключив исходные файлы в том же модуле и установив отдельный граф зависимостей. Опять же все они очень упрямы, и это только мое личное мнение. Я уверен, что другие думают иначе.

EDIT 2: Хорошо после обсуждений ниже, позвольте мне попытаться предложить более сжатый и менее самоуверенный ответ. Одна вещь, что веб-пакет действительно хорошо, это то, что можно смотреть, читать, готовить и обновлять кеш и обслуживать с минимальным объемом ввода-вывода и обработки файлов. Труба Gulp работает очень хорошо, но когда дело доходит до этапа комплектации, неизбежно заканчивается необходимость считывать все файлы из каталога temp, в том числе без изменений. По мере роста вашего проекта, время ожидания этого шага также растет. С другой стороны, webpack-dev-сервер сохраняет все в кэше в памяти, поэтому количество времени ожидания при разработке минимально. Однако для достижения такого кэширования памяти веб-пакет нужно будет покрывать от watch to server, поэтому вам нужно будет знать ваши конфигурации предварительной обработки. После того, как вы настроили webpack, чтобы сделать это, вы можете просто повторно использовать те же конфигурации, что и для выталкивания сборок, отличных от dev-сервера. Таким образом, мы оказались в этой ситуации. При этом точно, какие шаги вы хотите, чтобы веб-пакет делал, все еще зависит от ваших личных предпочтений. Например, я не занимаюсь обработкой изображений или lint в моем dev-сервере. На самом деле, мой шаг лайта - совершенно отдельная цель.