Webpack gulp: Integrations | webpack

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

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

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

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

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

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

Опущу подробности базовой настройки 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 и тд, но это тема отдельной статьи.

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

Сравнение систем сборки для frontend проекта

Лишь несколько лет назад использование инструментов сборки JavaScript выглядело бы смешно, из-за того, что JS интерпретируется браузером и не компилируется. Однако сложность проектов имеет тенденцию к экспоненциальному увеличению, и масштабы и проблемы, связанные с производительностью, обслуживанием и безопасностью, получили широкую огласку. В последнее время бум одностраничных приложений (SPA) только что добавил к проблеме.

В настоящее время, начиная со следующего проекта JavaScript, сборка системы является одной из приоритетных задач. Хотя такое разнообразие вариантов часто стоит на пути разработки самого приложения. Чтобы решить вышеупомянутые проблемы, а также автоматизировать такие задачи, как статический анализ кода, выполнение тестовых случаев и т. Д. — используются бегуны задач. Gulp vs Grunt — самая популярная дилемма. Они оба автоматизируют задачи, используют Node.js, и они одновременно эффективны и эффективны.

С другой стороны, Webpack является поставщиком, и он пригодится, когда вам нужно собрать несколько активов (изображения, шрифты и т. Д.) Вместе в граф зависимостей. Итак, как можно сравнить Gulp vs Grunt vs Webpack? Gulp и Webpack обычно используются вместе, но в настоящее время наблюдается тенденция к использованию последнего вместо инструмента построения gulp, в частности среди сообщества Reactjs. Это делается по нескольким причинам: этот мощный инструмент может выполнять почти все задачи, которые вы выполняете через бегун задачи; Он поставляется с вариантами минимизации и сопоставления исходных карт; Он может служить промежуточным программным обеспечением через настраиваемый сервер, а именно webpack-dev-server , который поддерживает как горячую, так и живую перезагрузку.

GruntJS — это инструмент командной строки для интерфейсных разработчиков для выполнения предопределенных повторяющихся задач. В то время как задачи определяются декларативно с помощью объектов конфигурации, которые обрабатываются плагинами, чтобы поддерживать базовый пакет в достаточном размере. Он используется для автоматизации рабочих процессов JavaScript, таких как объединение и минимизация JS-файлов, проведение тестов, обновление браузера для загрузки изменений скриптов и т. Д.

Плюсы:

Огромная экосистема плагинов для одновременного выполнения различных задач (более 6010 элементов в реестре плагинов Grunt)
Минусы :

Может усложниться по мере роста конфигурации
Отсутствие гибкости с необычными задачами
Тенденция к устареванию

Спустя 18 месяцев после Grunt GulpJS был выпущен. Это еще один инструментарий для определения и выполнения трудоемких задач, но он использует другой подход. Сравнивая Grunt vs Gulp, основное отличие заключается в том, что там, где GruntJS использует объекты конфигурации для декларирования задач, Gulp определяет их как функции JavaScript. Он основывается на концепциях трубопроводов (источники, фильтры, приемники), аналогичные операционным системам Unix.

Плюсы:

Большая ясность текущих процессов и больший контроль над потоком
Большая экосистема плагинов Gulp, в то время как каждый из них может выполнить определенную задачу (более 2770 различных плагинов для разных целей)
Более высокая производительность благодаря использованию потока и операциям с памятью
Требуется меньше кода, по сравнению с Grunt
Минусы:

Первоначально потоки и обещания трудно понять

Gulp.js vs Grunt.js: код и конфигурация

Это одно из главных различий в сравнении Gulp vs Grunt; Однако дилемма может быть меньше о конфигурации и кодировании, но о том, насколько удобна ваша команда с потоками узлов. Gulp — это больше о кодировании и использовании одноцелевых плагинов, в то время как Grunt использует конфигурационные и многоцелевые плагины.

Если вы знакомы с узлом, то с gulpfile вы почувствуете себя более комфортно. Из-за того, что он следует спецификации CommonJS, может показаться, что читать легче, хотя пользователи часто заявляют, что Grunt легче писать. Выбор в основном зависит от навыков вашей команды и опыта работы.

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

Сравнивая Webpack vs Grunt, первый из них предлагает большую гибкость и расширенную функциональность для современных интерфейсных проектов. Он поставляется с функциональным ядром и может быть расширен с использованием отдельных загрузчиков и плагинов. По сути, он используется для связывания модулей JavaScript с зависимостями в файлах, но для сложных приложений JavaScript с большим количеством не кодовых активов (изображения, шрифты, CSS и т. Д.) Он может принести большие выгоды.

Говоря о производительности Webpack vs Gulp vs Grunt, два последних рассматривают определенный путь для файлов, соответствующих вашей конфигурации, в то время как Webpack анализирует весь проект. Он просматривает все зависимости, обрабатывает их с помощью загрузчиков и создает связанный JS-файл.

Плюсы:

Идея графика зависимостей в Webpack обеспечивает более легкое разделение кода, контроль над обработкой активов и устранение мертвых активов
Множество опций и функций прямо из коробки
Webpack-dev-сервер поддерживает горячую и живую перезагрузку

Минусы:

Первоначально сложно настроить

Webpack vs Grunt vs Gulp 2017: что и когда использовать?

Нет единственного правильного или неправильного ответа, когда дело касается выбора инструментов сборки для ваших следующих проектов. Ваш выбор будет в основном зависеть от размера вашего проекта, вашего набора навыков и того, заинтересованы ли вы в кодировании (бегун задачи Gulp) или в настройке (инструмент построения Grunt и Webpack). Кроме того, личные предпочтения имеют большое влияние на ваш выбор, например, скорость работы, сроки выполнения проектов, доступные типы плагинов и т. Д.

Более того, выбор не ограничивается этими инструментами построения JavaScript, и есть много других альтернатив, таких как Browserify, JSPM или Brunch, просто для того, чтобы назвать несколько.

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

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

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

Многие разработчики нашли творческие решения этой проблемы, о чем я узнал во время бета-тестирования нашей совершенно новой функции мгновенного предварительного просмотра. С помощью 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 , чтобы создать новую задачу для последовательного запуска этих двух подзадач, а затем экспортировать ее, чтобы мы могли запустить ее в командной строке. Структура

 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 , чтобы предоставить версию функции, которая делает именно это.

 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('разработка'), перезагрузка)
    )
}
 

Здесь важно обратить внимание на пару вещей:

1. Чтобы просмотреть все файлы в проекте, мы можем просто использовать этот шаблон globstar : **/*
2. Мы хотим, чтобы все файлы, созданные в процессе сборки, были проигнорированы, иначе мы можем оказаться в бесконечном цикле перезагрузки. Для нашего проекта это означает игнорирование всего в 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 и Webpack вместе для объединения ресурсов

На GitHub есть репозиторий с файлами этой статьи.

Я люблю Webpack! Это позволяет мне объединять сценарии в один файл. И если вы соедините его с babel, вы можете использовать синтаксис javascript следующего поколения и по-прежнему делать свои сценарии совместимыми со старыми браузерами.

Дело в том, что если вы собираетесь создать полноценный javascript-проект, вам ДОЛЖЕН использоваться веб-пакет...

Но есть проблема... Webpack не предназначен для автоматизации задач, даже жестко он их умеет.

Для автоматизации задач я до сих пор считаю, что нет лучшего инструмента, чем gulp. Особенно, когда мы хотим скомпилировать файлы SASS, создать zip-архивы или развернуть код на удаленных серверах.

Итак, здесь я покажу, что вам нужно использовать gulp с webpack для автоматизации задач со следующими задачами:

• Одна задача для компиляции файлов SASS в файлы CSS
• Одна задача для компиляции файлов .js с помощью веб-пакета

Я не буду рассказывать о том, как делать сложные вещи, такие как развертывание или очистка, поскольку я просто хочу показать вам, как заставить эти два инструмента работать вместе.

TOC

• Настройка проекта.
• Создать package.json
• Установить глоток
• Установите и настройте компилятор sass
• Установите и настройте Webpack
• Добавление Babel в веб-пакет
• Настроить веб-пакет в Gulp
• Небольшая уборка
• Отсутствуют шаги

Настройка проекта.

Сначала создадим каталог проекта с несколькими подкаталогами:

 mkdir gulp-webpack-integration
cd gulp-webpack-интеграция
mkdir -p src/{js,scss}
дерево 

Тогда у вас должна получиться следующая структура:

 .
└── источник
    ├── js
    └── сксс
3 каталога, 0 файлов 

Теперь давайте создадим несколько тестовых файлов CSS и JS, чтобы нам было что тестировать:

Создать src/scss/main.scss со следующим содержимым:

 // src/scss/main.scss
$фоновый цвет: #4b16ff;
$ переднего плана: #ffffff;
тело {
  цвет фона: $фоновый цвет;
  цвет: $ переднего плана;
} 

Теперь создайте src/js/hola-mundo. js со следующим содержимым:

 // src/js/hola-mundo.js
экспорт по умолчанию HolaMundo = имя => {
  console.log(`Привет, ${имя} из hola-mundo.js`)
} 

И, наконец, создайте src/js/main.js с

 // src/js/main.js
импортировать HolaMundo из "./hola-mundo.js"
HolaMundo("Mario") 

Как видите, это очень простые файлы, но их достаточно для тестирования нашей установки.

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

• Запустите файл package.json npm
• Установка и настройка gulp
• Установите и настройте компилятор sass
• Установка и настройка веб-пакет
• Установите babel и настройте его с помощью веб-пакета
• Настроить веб-пакет в gulp

Create

 npm init -y 

 {
  "name": "gulp-webpack-integration",
  "версия": "1. 0.0",
  "описание": "",
  «основной»: «index.js»,
  "скрипты": {
    "test": "echo \"Ошибка: тест не указан\" && выход 1"
  },
  "ключевые слова": [],
  "автор": "",
  "лицензия": "ISC"
} 

 npm install --save-dev gulp 

3 9 //
const gulp = require("gulp") 

 npm install --save-dev gulp-sass node-sass 

 // gulpfile.js
const gulp = требуется ("глоток")
const sass = require("gulp-sass")sass.compiler = require("node-sass")function styles() { return gulp .src("src/scss/*.scss") .pipe(sass()) .pipe(gulp.dest("css/"))}exports.build = стили 94.13.0"
  }
} 

 npm install --save-dev webpack webpack-cli 

 // webpack.config.js
постоянный путь = требуется ("путь")
модуль.экспорт = {
  вход: {
    основной: ". /src/js/main.js",
  },
  выход: {
    имя файла: "[имя].min.js",
    путь: path.resolve(__dirname, "js"),
  },
} 

 // пакет.json
{
  ...
  "скрипты": {
    "сборка": "сборка залпом",
    "webpack": "webpack --mode=development" },
  ...
} 

 npm install --save-dev babel-loader @babel/core @babel/cli @babel/preset-env 

 // webpack.config.js
постоянный путь = требуется ("путь")
модуль.экспорт = {
  вход: {
    основной: "./src/js/main.js",
  },
  выход: {
    имя файла: "[имя].min.js",
    путь: path.resolve(__dirname, "js"),
  },
  модуль: { правила: [ { тест: /\.js$/, исключить: /node_modules/, загрузчик: "babel-loader", опции: { пресеты: ["@babel/preset-env"], }, }, ], },} 

 npm install --save-dev webpack-stream 

 // gulpfile.js
const gulp = требуется ("глоток")
const sass = требуется ("глоток-дерзость")
const веб-пакет = требуется ("веб-пакет-поток")
sass.compiler = требуется («узел-дерзость»)
стили функций () {
  обратный глоток
    .src("Источник/scss/*.scss")
    .pipe(дерзко())
    .pipe(gulp.dest("css/"))
}
function scripts() { return gulp .src(".") .pipe(webpack(require("./webpack.config.js"))) .pipe(gulp.dest("js/"))}
exports.build = gulp.parallel(стили, скрипты) 

 // пакет. json
{
  ...
  "скрипты": {
    "build": "NODE_ENV=производственная сборка gulp", "dev": "сборка gulp", "webpack": "webpack --mode=development"
  },
  ...
} 

 // webpack.config.js
постоянный путь = требуется ("путь")
модуль.экспорт = {
  вход: {
    основной: "./src/js/main.js",
  },
  выход: {
    имя файла: "[имя].min.js",
    путь: path.resolve(__dirname, "js"),
  },
  модуль: {
    правила: [
      {
        тест: /\.js$/,
        исключить: /node_modules/,
        загрузчик: "бабель-загрузчик",
        параметры: {
          пресеты: ["@babel/preset-env"],
        },
      },
    ],
  },
  режим: process.env.NODE_ENV == "производство"? "производство" : "разработка",}