Подтвердить что ты не робот

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

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

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

4b9b3361

Ответ 1

Я уверен, что у других есть свои причины, но самая большая причина, по которой я перешел на webpack (более конкретно webpack-dev-server), заключается в том, что он служит вашему пакету из памяти (в отличие от диска), и его наблюдатель будет перекомпилировать только файлы, которые вы изменили при повторном использовании остальных из кеша (в памяти). Это позволяет быстрее развиваться. Я имею в виду, что, когда я активно редактирую код, я могу ctrl + s в Sublime Text, к тому времени, когда я переместил alt + tab в Chrome, он уже выполнил перестройку. Раньше у меня была грубая + браузерная + установка с использованием grunt-watch, и потребовалось не менее 5 секунд, чтобы перестраивать каждый раз, когда я сохраняю (то есть после того, как я создал кучу специализированных оптимизаций в сборке grunt). При этом я по-прежнему интегрировал webpack с gulp, поэтому у меня появился руководитель задачи для моего проекта.

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

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

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