Gulp webpack: Integrations | webpack — Вебджем.рф | Создание и продвижение сайтов

Содержание

Настраиваем Gulp и Webpack для “обычной” верстки сайтов (с jQuery). Февраль 2018. | by Artur Valeyev

“Colorful lines of code on a MacBook screen” by Caspar Rubin on Unsplash

Прошлая моя статья о настройке связки Gulp + Webpack+ Babel + React оказалась довольно популярной, но, как и всё в мире front-end’а, она устарела моментально, и сейчас вполне может оказаться, что проект с таким конфигом “не заведется”.

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

О чем я хочу тут рассказать:
Я до сих пор часто верстаю “обычные” сайты, где не нужны фреймворки, шаблонизаторы и тд. Но при этом грамотная сборка SCSS и JavaScript — это то, что ускоряет разработку и улучшает читабельность и качество кода, поэтому от нее отказываться нельзя.
Я использую Gulp в качестве task-runner’а. А для сборки JavaScript я решил воспользоваться Webpack’ом. Вот о его настройке в рамках таких проектов и хочу поведать.

Что для меня важно:

jQuery в проекте — как внешняя библиотека. Подключается через CDN — так экономится трафик у пользователя
Поддержка ES6 — модульность, да и просто полезно
Два выходных файла — один из них минимизированный, идет на продакшн.

Опущу подробности базовой настройки Gulp, сразу к делу.
Для поддержки ES6 будем использовать Babel.

Необходимые пакеты:

npm install --save-dev gulp gulp-uglify gulp-rename webpack webpack-stream babel-core babel-loader babel-preset-env jquery

Структура проекта:

public
- index.html
src
- js/app.js
package.json
gulpfile.js

В src у нас лежат все исходники (в нашем случае — только JS), в public — скомпилированный код.

Сразу весь необходимый код (github gist не дает разделить файлы одного гиста):

Подробно:
package. json я привожу просто, чтобы было видно версии используемых пакетов.
index.html — чтобы показать, что jQuery подключен через CDN.

app.js — это исходник наших скриптов (лежит в src/js/). Как видите, там jQuery подключен как модуль, и уже есть конструкции ES6 (стрелочные функции и шаблонные строки, кто не пробовал — обязательно начните использовать).

gulfile.js — тут весь необходимый конфиг. Можно вынести настройки webpack в его собственный файл настроек webpack.config.js, но у нас их немного — поэтому, думаю, можно оставить.

Как это все работает

Webpack мы используем с помощью webpack-stream, потому что нужно обеспечивать его работу в потоке gulp задачи.
Gulp берет исходный файл ./src/js/app.js и передает его в webpack. В настройках webpack’а указано использовать лоадер babel-loader, который обеспечит нам ES6. В лоадер мы даем установку использовать презет env (это рекомендация Babel). При этом в конфиге также есть параметр externals, который позволяет сказать webpack’у, что jquery у нас — это внешняя библиотека, и не нужно включать ее в бандл.
После вебпака мы получаем готовый бандл, но по умолчанию выходное имя файла будет содержать хэш (дефолтный параметр webpack), поэтому в настройке мы также указываем необходимое имя файла.
Сохраняем файл, но нам нужна еще минифицированная версия. Для этого мы сначала используем gulp-uglify чтобы сжать файл, а потом — gulp-rename чтобы добавить имени файла суффикс .min, и еще раз сохраняем. Всё.
Вызывается таск просто: либо gulp scripts либо npm run build

Это минимальная настройка, которая удовлетворяет указанные выше требования. Можно еще настроить webpack, чтобы он сам сжимал файлы своими алгоритмами, добавлял source map и тд, но это тема отдельной статьи.

Надеюсь, мои знания будут Вам полезны!

Gulp vs Webpack | Readvus

В профессиональном сообществе не утихают споры, относительно того, какой инструмент использовать в работе. Сегодня речь пойдет о таких инструментах, как Gulp и Webpack.

В последнее время набирает обороты какая-то нездоровая идеализация инструментов, в отрыве от целей, задач и конечного результата. Если ты не используешь какой-то определенный инструмент, значит ты не профи. Если используешь, добро пожаловать в клуб, и не важно, что в результате у тебя получается какашка. Такого холиварного бума, далекого от сути вопроса, не было даже во времена «Photoshop vs Open Source». Складывается впечатление, что инструмент первостепенен, а не сама область, не результирующий продукт и это довольно печально. Наряду со страхом остаться без денег, у современного веб-разработчика из России и СНГ добавилась новая фобия — использовать НЕ трендовый инструмент, в страхе умереть вместе с ним. Вообще, в своих видео я не однократно обращал ваше внимание на то, что если кто-то говорит, что какой-то инструмент или технология умирает — задумайтесь об объективности таких выводов. Ближе к делу.

Итак, Gulp и Webpack. Основы. Давайте начнем с определений. Изначально, эти инструменты позиционируются создателями, как инструменты для решения несколько разных задач. Webpack позиционируется, как мощный комбайн-бандлер, предназначенный для удобной разработки JS Application и одностраничных приложений. Кроме того, он имеет множество полезных дополнений для решения повседневных задач — препроцессоры, картинки и прочее, которые являются лишь бонусами к основе. Gulp — это таск-ранер, упрощающий жизнь, благодаря автоматизации выполнения каких-то рутинных задач. В принципе, на этом можно было бы остановиться, ведь мы поняли из определений, что это разные инструменты и, в общем-то, они предназначены для разных задач, если бы не одно НО. Почему-то эти два инструмента каким-то странным образом попадают на один график в Google Trends и вызывают бурление в профессиональной среде, Webpack начинают использовать даже там, где не стоит задачи разработки приложения, в угоду трендам, а Gulp несправедливо причисляют к списку инструментов на вымирание.

Давайте разберем типичный сценарий перехода с Gulp на Webpack и формирования мнения. Начинающий разработчик, поняв мироустройство веб-разработки, как области, стоит перед выбором — уйти в дизайн или углубиться в JS разработку. Допустим, он выбирает JS, так как данная область ему ближе, начинает изучать рынок инструментов и понимает, что для профессиональной глубокой JS-разработки уже есть крутой инструмент, который позволит ему решить массу проблем одним махом. И этот инструмент, справедливо и безоговорочно — Webpack. Стандарт индустрии. Далее у нашего разработчика появляются и другие задачи — работа с изображениями, препроцессинг и так далее, и он начинает грустить и вспоминать старый добрый Gulp. Однако, его печаль продолжается недолго, ведь он узнает, что Webpack дает таки возможность, окромя работы с JS, инструменты для решения поставленных задач. Теперь есть все вопросы закрыты. Новый оппозиционер Gulp и новая боевая единица для холивара окончательно сформировалась, положительный опыт подкреплен. Теперь этот персонаж будет на право и налево пропагандировать, насколько крут его инструмент (а это, к слову, действительно так, инструмент действительно крут для своих задач), охотно ввязываясь в споры на форумах и советовать свой инструмент даже там, где он не нужен. Речь идёт о веб-дизайне и верстке. У нас эти понятия принято относить к разным областям, но по сути — это грани одной специализации.

Не стоит забывать, что мир веб-разработки не делится на черное и белое. Кроме области дизайна и области программирования в сферическом вакууме, есть и другие области. Это, в первую очередь, разработка коммерческих проектов на CMS, заказная разработка, конвейерная разработка, огромный пласт индустрии, не нуждающийся в Вебпаке, как первостепенном инструменте, ведь здесь не идет речи о создании приложений. Окромя компаний, которые занимаются созданием SPA, работающие в команде над одним единственным проектом, есть и другие области, другие рынки. И начинающие разработчики, дизайнеры, начитавшись отзывов, насмотревшись на тренды, формируют неправильное понимание рынка инструментов, начинают использовать не то, что им нужно, боясь быть не актуальными, не современными. И это ловушка. Они видят популярность инструмента, абсолютно не понимая природы такой популярности и области применения. Будьте рациональны, дорогие друзья.

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

Поэтому дорогие друзья, лучше использовать те инструменты, которые вам по душе, применять их по назначению и работать в свое удовольствие. Это всего лишь инструменты.

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

Оригинал статьи

Gulp и Webpack: лучшее из обоих миров

Когда-то я говорил вам, что Webpack — отличный инструмент для управления JavaScript в ваших веб-проектах. Это связано с тем, что Webpack позволяет вам писать модульный JavaScript для браузера и обрабатывает разрешение зависимостей и объединение файлов. Я сравнил Webpack с Gulp, потоковым процессором и утилитой запуска задач, которая, хотя и имеет свое место, не выполняет сложного объединения модулей, которое делает Webpack. Это делает Gulp менее привлекательным вариантом для упаковки файлов JavaScript.

Одна проблема с любым конвейером ресурсов возникает при его использовании вместе с генератором статических сайтов. У вас есть один инструмент для создания вашего JavaScript и CSS и другой инструмент для создания HTML вашего сайта. По большей части это довольно незначительное неудобство: ваш сценарий развертывания может просто запускать команды отдельно, и, возможно, в вашей среде разработки вы можете запускать команду watch Webpack и сервер разработки SSG в отдельных окнах терминала.

Немного неэлегантное решение, но вполне работоспособное.

Многие разработчики нашли творческие решения этой проблемы, о чем я узнал во время бета-тестирования нашей совершенно новой функции Instant Previews. С помощью Instant Previews компания Forestry может запускать сервер разработки вашего генератора статических сайтов в нашей облачной среде предварительного просмотра, что значительно сокращает время, необходимое для восстановления вашего предварительного просмотра. К сожалению, некоторые из этих несовершенных, но пригодных для использования решений , которые работали в средах предварительного просмотра разработчиков, не так хорошо работают с мгновенными предварительными просмотрами — запуск нескольких команд не является простым, а несколько параллельных команд могут привести к условиям гонки.

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

Это не должно быть так сложно: какой хороший инструмент позволит мне организовать серию команд, отслеживать файлы на наличие изменений и запускать сервер разработки?

Мы снова встретимся, старый друг.

Конечно же, Gulp идеально подходит для этого.

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

Это будет действительно легко , я обещаю.

Начало работы с Gulp

Для целей этого руководства предположим, что у вас есть сайт Hugo, который использует Webpack для создания ресурсов. Если вы используете другой генератор статических сайтов, такой как Jekyll, продолжайте читать: его будет легко адаптировать к нескольким различным SSG.

Поскольку у вас уже настроена сборка Webpack, можно с уверенностью предположить, что в вашей среде уже есть Node и NPM, а в вашем проекте уже есть файл package. json с вашими зависимостями Webpack. Чтобы добавить Gulp в свой проект, просто установите его через NPM следующим образом:

 npm install --save gulp

В этом руководстве используется последняя текущая версия Gulp, которая на момент написания была 4.0.0 . Если вы читаете это в будущем и сталкиваетесь с проблемами, вы можете убедиться, что используете совместимую версию Gulp:

 npm install --save [email protected]

Создание задач

Мы собираемся определить ряд задач, которые будут запускать все основные компоненты нашей сборки один за другим. В конечном итоге мы создадим две команды Gulp: команду

build , которая создаст наш сайт для развертывания, и команду develop , которая запустит сервер разработки, который перестраивает и перезагружает сайт в ответ на изменения.

Для команды build потребуются две задачи:

Сборка ресурсов Webpack
Запустить генератор статических сайтов

Команда develop будет аналогична команде build, но с несколькими дополнительными шагами:

Сборка ресурсов Webpack
Запустить генератор статических сайтов
Запустить сервер разработки
Следите за изменениями в файлах, повторно запускайте сборки и перезагружайте сервер разработки

После установки Gulp создайте новый файл с именем gulpfile.

js в корне вашего репозитория. В верхней части этого файла добавьте следующую строку для загрузки пакета gulp для загрузки gulp в этом контексте:

 const gulp = require("gulp")

Самый простой способ создать задачу Gulp — определить функцию в gulpfile.js . Gulp передает вашей задаче функцию обратного вызова, которую следует использовать, чтобы сообщить, что ваша задача завершена.

 функция someTask(cb) {
    // сделать что-то
    кб()
}

Кроме того, вы можете просто обернуть свой код в Promise :

 function someTask(cb) {
    вернуть новое обещание ((разрешить, отклонить) => {
        // сделать что-то
        решать()
    })
}

Чтобы запустить эту задачу в командной строке, вам нужно ее экспортировать:

 exports.someTask = someTask

В этот момент вы можете выполнить задачу с помощью следующей команды:

 gulp someTask

Если у вас не установлен глобально Gulp, запуск 9Команда 0037 gulp может не работать. В конце концов, мы собираемся запустить нашу команду gulp как скрипт NPM, который правильно определит путь к нашим установленным модулям, так что это не проблема.

Настройка конвейера сборки

Для начала мы настроим базовый конвейер сборки. Это просто запустит сборку Webpack и подождет, пока ресурсы не будут сгенерированы, прежде чем запускать сборку SSG. Мы можем использовать gulp.series , чтобы создать новую задачу для последовательного запуска этих двух подзадач, а затем экспортировать ее, чтобы мы могли запустить ее в командной строке. Структура gulpfile.js будет выглядеть примерно так:

 const gulp = require('gulp')
функциональные активы (cb) {
    // запускаем вебпак
}
функция ssg(cb) {
    // запускаем команду SSG
}
// экспортировать задачу сборки, которая запускает две вышеуказанные задачи последовательно
exports.build = gulp.series (активы, ssg)

Создание задачи Webpack

К счастью для нас, Webpack имеет Node API, который позволяет нам вызывать его из среды Node, поэтому включить его в задачу Gulp будет очень просто.

Сначала потребуется модуль webpack в gulpfile.js (если вы добавляете это в существующий проект Webpack, у вас уже будет установлен Webpack.)

 const webpack = require('webpack')
const webpackConfig = требуется('./webpack.config.js')

Вы заметите, что мы также загружаем конфигурацию Webpack. Если ваша конфигурация Webpack находится где-то кроме webpack.config.js в корне вашего проекта, вам нужно будет изменить путь в приведенном выше коде.

Чтобы запустить Webpack, нам просто нужно вызвать функцию webpack из модуля и передать ей наш webpackConfig . Однако, чтобы это хорошо работало с Gulp, мы должны обернуть его в промис, который может обрабатывать состояния успеха и ошибки:

 function assets(cb) {
    вернуть новое обещание ((разрешить, отклонить) => {
        webpack(webpackConfig, (ошибка, статистика) => {
            если (ошибка) {
                вернуть отказ (ошибка)
            }
            если (stats. hasErrors()) {
                вернуть отклонение (новая ошибка (stats.compilation.errors.join ('\ n')))
            }
            решать()
        })
    })
}

Всё! Прелесть этого решения в том, что оно будет работать с любой конфигурацией Webpack , и если вы вносите обновления в конвейер ресурсов, вам не нужно вносить какие-либо изменения в этот файл.

Создание задачи SSG

Hugo, конечно, не имеет Node API, но мы можем разумно предположить, что собираемся запустить нашу сборку в среде, имеющей доступ к команде Hugo , мы будем использовать Node встроенный модуль child_process для запуска Hugo , как если бы мы вызывали его из командной строки.

Мы собираемся использовать функцию execFile модуля child_process . Для достижения наилучших результатов было бы здорово, если бы execFile возвращал обещание . К счастью, мы можем использовать utils. promisify , чтобы предоставить версию функции, которая делает именно это. Добавьте следующие строки в начало gulpfile.js вместе с остальным импортом:

 const util = require('util')
const execFile = util.promisify(require('child_process').execFile)

Тогда все, что вам нужно сделать для реализации функции ssg , это:

 function ssg(cb) {
    вернуть execFile('Хьюго')
}

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

 функция ssg(env) {
    если (env === 'производство') {
        return Hugo = cb => execFile('Hugo')
    }
    return Hugo = cb => execFile('Hugo', ['-D','-F'])
}

Если приведенный выше код выглядит немного странно, для этого есть веская причина.

  Вы можете просто вернуть  cb => execFile('hugo')  без ненужного присваивания, но выходные данные Gulp в терминале идентифицируют задачи по именам их функций. Таким образом, назначив функцию стрелки перед ее возвратом, имя задачи появится в терминале как  Хьюго  (в отличие от  <анонимно>  ).
 С этой модификацией нам нужно изменить нашу задачу  build . Поскольку функция  ssg  теперь  возвращает  задачу Gulp, вместо того, чтобы быть самой задачей Gulp, мы изменим строку с
 exports.build = gulp.series(assets, ssg)
 
 -
 exports.build = gulp.series(assets, ssg('production'))
 
 Добавление сценария NPM 
 Как упоминалось ранее, рекомендуется запускать эти задачи в виде сценария NPM, поскольку в этом случае он может автоматически разрешать любые локально установленные модули. Мы сделаем это, добавив  scripts 
  раздел для  package. json  . Если у вас уже есть раздел  scripts  в этом файле, не стесняйтесь добавлять или изменять в нем команды.
 {
    ...
    "скрипты": {
    "сборка": "сборка залпом"
    }
} 
 После того, как скрипт добавлен, вы можете вызвать его из командной строки с помощью  npm run  :
 npm run build 
 Настройка конвейера разработки 
 Теперь, когда у нас есть базовый конвейер сборки, есть еще пара шагов, чтобы добавить сервер разработки с перезагрузкой в реальном времени. Вместо использования  Hugo serve  , мы собираемся продолжить сборку сайта с помощью команды  Hugo  и запустить сервер разработки через Gulp.
 Browsersync 
 Для запуска нашего сервера разработки мы будем использовать BrowserSync. Сначала установите его:
 npm install --save browser-sync 
 Затем загрузите его поверх  gulpfile.js  с остальным импортом:
 const browserSync = require('browser-sync') . Создайте()
 
 Наконец, мы создадим новую задачу Gulp с именем  служит , который запускает сервер BrowserSync, вызывая его функцию  init . Второй параметр, переданный в  init , — это функция обратного вызова, которая сработает, когда сервер будет готов, поэтому здесь мы передадим сигнальную функцию Gulp в качестве обратного вызова.
 функция serve(cb) {
    browserSync.init({
        сервер: "./public",
        порт: 8080,
        хост: "0.0.0.0"
    }, сп)
}
 
 Потому что команда  Hugo  создаст наш сайт до  ./public , мы устанавливаем его как корень документа нашего сервера. Если вы используете другой SSG или создаете свой сайт в другом каталоге, вам нужно изменить это.
 Мы выбрали здесь привязку к  0.0.0.0:8080  для совместимости с мгновенными предварительными просмотрами Forestry.
 Дополнительно создадим задачу на перезагрузку сервера:
 function reload(cb) {
    браузерSync. reload()
    кб()
}
 
 Live Reloading 
 Мы можем использовать часы Gulp  9Функция 0038 для просмотра файлов на наличие изменений и запуска задачи в ответ:
 function watch (cb) {
    вернуть gulp.watch(
        '**/*', // смотреть все...
        {
            игнорируется: [
                // ...за исключением вещей, созданных в процессе сборки.
                'общедоступный/**/*',
                'статические/активы/**/*'
            ]
        },
        // когда что-то меняется, пересобираем + перезагружаем
        gulp.series(активы, ssg('разработка'), перезагрузка)
    )
}
 
 Здесь важно обратить внимание на пару вещей:
 Чтобы просмотреть все файлы в проекте, мы можем просто использовать этот шаблон  globstar :  **/* 
 Мы хотим быть уверены, что игнорируем любые файлы, созданные в процессе сборки, иначе мы можем попасть в бесконечный цикл перезагрузки. Для нашего проекта это означает игнорирование всего в  public  (где создан сайт), а также всего в  static/assets  (где создаются активы). В зависимости от того, как настроен ваш сайт, вам может понадобиться чтобы изменить эти правила.
 Теперь, когда это сделано, нам просто нужно создать и экспортировать задачу  разработки , запустив следующую серию:
 exports.develop = gulp.series(assets, ssg('development'), serve, watch)
 
 Это запустит первоначальную сборку, запустит сервер BrowserSync, а затем просмотрит файлы на наличие изменений, запустив последовательность восстановления и перезагрузки, определенную в нашей задаче  watch .
 Осталось только добавить соответствующий скрипт NPM:
 {
    ...
    "скрипты": {
        "сборка": "сборка залпом",
        "развивать": "разрабатывать глотком"
    }
} 
 Теперь, когда мы запустим  npm run develop  , он запустит сервер разработки, создав ресурсы Webpack и сайт Hugo в одной последовательности. При использовании сайта с мгновенным предварительным просмотром Forestry вы можете просто установить команду мгновенного предварительного просмотра на  npm run develop  .
 Глоток, да? Хорошо! 
 Мудрость заключается в использовании правильного инструмента для работы. Если классифицировать и Gulp, и Webpack как «инструменты сборки», использование обоих будет излишним, но в данном случае они отлично работают вместе. Я уже объяснял, почему мне нравится использовать Webpack, но вот что мне нравится в этом конкретном решении Gulp:
 Работает с любым генератором статических сайтов, который может работать в вашем терминале
 Работает с различными конфигурациями Webpack без модификации
 Добавляет BrowserSync и перезагрузку в реальном времени для любого SSG
 Облегчает работу с мгновенными предварительными просмотрами Forestry
 Вы можете скачать весь  gulpfile.js  из этого списка. Если вы не используете Hugo, все равно должно быть довольно просто адаптировать его к любому SSG, который вы используете.
 И на этом все, что осталось сказать:  ладно, увидимся позже! 
 Gulp.
 js и Webpack — какой из них использовать и когда? Веб-разработка, особенно когда речь идет о JavaScript, требует большой точности, усилий и надлежащего планирования. Без этого не только проекты могут занимать слишком много времени, но и разработка сложных приложений может показаться почти невозможной.
 Это потому, что мы, веб-разработчики, больше не работаем только с HTML-кодом. Вместо этого акцент смещается на сложные приложения, которые можно развертывать для самых разных целей — управление данными, одностраничные приложения, PWA и т. д.!
 Итак, когда дело доходит до разработки JavaScript, в нашем распоряжении есть ряд инструментов, облегчающих жизнь. Среди таких инструментов особенно выделяются два имени — gulp.js (обычно называемый gulp) и webpack.
 В этой статье мы узнаем больше о gulp и webpack, а также поймем, как каждый из них может помочь нам в нашем рабочем процессе разработки.
 Проще говоря, gulp — это система потоковой сборки, которая может помочь нам автоматизировать несколько задач. Другими словами, мы можем использовать gulp, чтобы позаботиться об общих действиях и задачах, которые в остальном важны и почти всегда выполняются, но многократное выполнение одного и того же обычно отнимает много нашего времени.
 И когда мы говорим о «задачах», мы имеем в виду такие действия, как минимизация кода CSS или JS, компиляция файлов SASS или LESS, преобразование значков SVG в шрифты, просмотр файлов на наличие изменений и другие действия и так далее.
 Используя gulp, мы можем автоматизировать такие задачи. Естественно, это может иметь большое значение для экономии нашего времени. Задачи Gulp — это простые асинхронные функции JS, которые принимают обратные вызовы с ошибкой.
 Узнайте больше о gulp здесь.
 webpack — это сборщик модулей для JavaScript. Это означает, что он может принимать модули с зависимостями, а затем генерировать статические ресурсы, которые являются представителями указанных модулей.
 Учитывая тот факт, что webpack является сборщиком модулей, в идеале он может работать бок о бок с исполнителем задач, таким как gulp. js
 Однако в современном мире разработки JavaScript границы между сборщиками модулей и исполнителями задач становились все более размытыми. Это связано с тем, что веб-пакет обладает высокой расширяемостью и может быть расширен с помощью пользовательских плагинов. Таким образом, благодаря плагинам, разработанным сообществом для веб-пакета, теперь мы можем использовать веб-пакет для выполнения действий, которые изначально выходили за рамки этого инструмента, например для управления задачами.
 В результате, webpack теперь вырос за пределы своего прежнего статуса и часто используется для замены таких инструментов, как gulp.js, при использовании в сочетании с его плагинами.
 Проще говоря, webpack принимает несколько модулей с зависимостями. Это могут быть файлы PNG, сценарии SASS и CSS, другие форматы файлов изображений и мультимедиа и т. д. Затем webpack объединяет их, чтобы предоставить нам согласованные статические ресурсы, которые мы можем развернуть в течение нескольких минут.
 Узнайте больше о webpack здесь.
 Используете webpack или gulp.js? Скопировать ссылку 
 Хотя gulp.js и webpack — это разные инструменты, в настоящее время они оба служат более или менее схожим целям. Таким образом, многие разработчики JavaScript часто заменяют gulp.js веб-пакетом и используют последний в качестве основного инструмента для повышения производительности и лучшего управления рабочим процессом.
 Это, очевидно, больше основано на практических наблюдениях, и фактический пробег может варьироваться от одного кодера к другому. В результате очень мало доказательств того, что gulp.js является более слабым инструментом по сравнению с webpack или наоборот. На самом деле, webpack — это связыватель модулей, тогда как gulp.js — средство запуска задач — само это определение подразумевает, что мы можем использовать оба инструмента в сочетании друг с другом практически без конфликтов.
 Но из-за широкого набора функций webpack многие разработчики используют webpack в качестве замены gulp. js — webpack предоставляет решения и настройки для минификации и сопоставления исходников, а в некоторых случаях даже может работать как промежуточное ПО. На самом деле, помимо модульного тестирования и анализа, вебпак мало что может сделать. Вот почему использование веб-пакета может помочь нам избежать дополнительных проблем с добавлением gulp.js в наши проекты.
 Однако стоит отметить, что gulp.js гораздо проще настроить и настроить, чем webpack. Это делает gulp.js более разумным и очевидным выбором для многих разработчиков-новичков. Однако, несмотря на то, что его проще настроить, gulp.js также можно адаптировать для более крупных и сложных рабочих процессов, если и когда это необходимо.
 Проще говоря, нет правильного или неправильного ответа, когда дело доходит до выбора между Gulp или Webpack. С учетом сказанного, оба являются разными категориями инструментов и могут очень хорошо использоваться в сочетании друг с другом.
 В зависимости от характера проекта, над которым мы работаем, а также наших основных требований, мы можем выбрать любой из двух вариантов.