Способ автоматически перезапускать webpack при изменении файла

Обновлено: 07.07.2024

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

Погрузчики стилей

Сначала создайте обычный CSS-файл в каталоге стилей. Вызовите main.css и добавьте правило стиля для элемента заголовка.

Итак, как мы можем получить эту таблицу стилей на нашей странице? Ну, как и большинство случаев с Webpack, нам понадобится еще один загрузчик. Два на самом деле: css-загрузчик и style-загрузчик. Первый читает все стили из наших файлов CSS, в то время как другой добавляет эти стили на нашу HTML-страницу. Устанавливаем их следующим образом:

Затем мы укажем Webpack, как их использовать. В webpack.config.js нам нужно добавить еще один объект в массив загрузчиков. В нем мы хотим добавить тест, чтобы сопоставить только файлы CSS, а также указать, какие загрузчики использовать.

Интересной частью этого фрагмента кода является строка 'style!css' . Погрузчики читаются справа налево, поэтому это говорит Webpack сначала прочитать стили любого файла, заканчивающегося на .css , а затем вставить эти стили на нашу страницу.

Поскольку мы обновили наш файл конфигурации, нам необходимо перезапустить сервер разработки, чтобы наши изменения были подхвачены. Используем ctrl + c , чтобы остановить сервер и webpack-dev-server , чтобы снова запустить его.

Все, что нам нужно сделать, теперь требует, чтобы наша таблица стилей была в нашем файле main.js . Мы делаем это так же, как и любой другой модуль JavaScript:

Обратите внимание, что мы даже не коснулись index.html . Откройте браузер, чтобы увидеть страницу со стилизованным h2 . Измените цвет заголовка в таблице стилей, чтобы увидеть его мгновенное изменение без обновления. Прекрасно.

Нам теперь нужно использовать Sass

"Но в наши дни никто не использует CSS, дедушка! Нужно использовать Sass". Конечно это так. К счастью, у Webpack есть загрузчик, чтобы сделать именно это. Установите его используя:

Затем обновите файл webpack.config.js :

Это говорит о том, что для любого файла, заканчивающегося на .scss , преобразуйте Sass в простой CSS, прочитайте стили из CSS и затем вставьте стили на страницу. Не забудьте переименовать main.css в main.scss , и вместо этого потребуется только что указанный файл. Сначала идет Sass:

Супер. Это так просто. Нет конвертирования и сохранения файлов или даже просмотра папок. Мы просто запрашиваем в наших стилях Sass напрямую.

Картинки

"Ну для картинок тоже свой загрузчик?" Конечно! С изображениями нам нужно использовать url-loader. Этот загрузчик берет относительный URL вашего изображения и обновляет путь, чтобы он правильно включался в ваш пакет файлов. По обыкновению:

Теперь давайте попробуем что-нибудь другое в нашем файле webpack.config.js . Добавьте еще одну запись в массив загрузчиков обычным способом, но на этот раз мы хотим, чтобы регулярное выражение соответствовало изображениям с разными расширениями файлов:

Обратите внимание на одно отличие. Мы не используем ключ exclude . Вместо этого мы используем include . Это будет более эффективно, поскольку он говорит webpack игнорировать все, что не соответствует папке под названием «images».

Обычно вы будете использовать какую-то систему шаблонов для создания своих HTML-представлений, но мы собираемся сохранить ее базовую и создать статичный образ в JavaScript. Сначала создайте элемент изображения, установите требуемое изображение в атрибут src, а затем добавьте элемент на страницу.

Вернитесь в свой браузер, чтобы ваше изображение появилось на ваших глазах!

Предварительная загрузка

Другая задача, обычно выполняемая во время разработки, - это проверка кода. Linting - это способ взглянуть на возможные ошибки в вашем коде, а также проверить, что вы следовали определенным правилам кодирования. Это такие вещи, как например, - «Я использовал переменную, не объявив ее сначала?» или "Забыл ли я поставить точку с запятой в конце строки?" Соблюдая эти правила, мы можем на ранней стадии отсеять глупые ошибки.

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

Установите jshint-загрузчик обычным способом:

Снова мы должны указать Webpack использовать его, добавив его в наш webpack.config.js . Однако этот загрузчик немного отличается. На самом деле он не про преобразование любого кода - он просто его просматривает. Мы также не хотим, чтобы все наши более тяжелые модифицирующие код загрузчики запускались и выходили из строя только потому, что мы забыли точку с запятой. Тут нам помогут прелоадеры. Предзагрузчик - это любой загрузчик, который мы указываем для выполнения перед нашими главными задачами. Они добавляются в наш файл webpack.conf.js аналогично загрузчикам.

Теперь наш процесс изготовления линта проходит и немедленно завершается, если обнаружена проблема. Прежде чем перезапустить наш веб-сервер, мы должны сообщить JSHint, что мы используем ES6, иначе он завершится ошибкой, когда увидит ключевое слово const , которое мы используем.

После ключа модуля в нашей конфигурации добавьте еще одну запись, названную «jshint», и строку, чтобы указать версию JavaScript.

Сохраните файл и перезапустите webpack-dev-server . Запустился нормально? Отлично. Это означает, что ваш код не содержит ошибок. Добавим одну ошибку, удалив точку с запятой из этой строки:

Снова сохраните файл и посмотрите на терминал. Теперь мы получаем следующее:

Подготовка к продакшену

Теперь, когда мы рады, что наш код в форме, и он делает все, что нам нужно, мы должны подготовить его к реальному приложению. Одна из наиболее распространенных вещей, которую нужно сделать, когда вы выкладываете свой код, состоит в том, чтобы минимизировать его, объединить все ваши файлы в один и затем сжать его в самый маленький возможный файл. Прежде чем продолжить, ознакомьтесь с текущим файлов bundle.js . Он читабельен, имеет множество пробелов и имеет размер 32 КБ.

"Погодите! Только не говорите мне. Еще один загрузчик, да?" Неа! В этом редком случае нам не нужен загрузчик. В Webpack встроена минимализация. Как только вы довольны своим кодом, просто запустите эту команду:

Флаг -p сообщает Webpack, чтобы наш код был готов для продакшена. Поскольку он генерирует пакет, он оптимизирует столько, сколько может. После запуска этой команды откройте bundle.js , и вы увидите, что все это было сжато вместе, и что даже с таким небольшим количеством кода мы сохранили 10 КБ.

Резюме

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

Наша платформа voximplant активно использует javascript. С помощью него клиенты управляют в реальном времени звонками, на нем работает наша backend логика и большинство frontend. Javascript мы любим, ценим и стараемся быть в курсе последних новостей. Сейчас наши разработчики активно экспериментируют с перспективной связкой webpack + typescript + react (кстати, для typescript мы сделали type definitions к нашему web sdk, но об этом как-нибудь в другой раз).

Особенно нам нравится «hot module replacement»: возможность при изменении исходников очень быстро отобразить изменения в браузере без перезагрузки страницы. Выглядит как магия. К сожалению, документировано тоже как магия — по словам eyeofhell, нашего технического евангелиста, «пример на офсайте — это уникальная комбинация частных случаев и особых команд, любое изменение в которых делает его неработоспособным». На наш взгляд все не так плохо, за пару вечеров вполне можно разобраться. Но и не так просто, как хотелось бы. Поэтому специально для Хабра под катом мы максимально просто и понятно расскажем как работает под капотом вся эта машинерия.

Официальный пример использования hot module replacement очень прост. Авторы предлагают создать файл style.css с одним стилем:

И файл entry.js, который использует основную фичу webpack, команду require, чтобы добавить .css файл к содержимому страницы. Ну и создает элемент типа input, на котором можно проверить hot module replacement:

Далее предлагается запустить webpack с помощью заклинания

И открыть страницу, доступную по адресу localhost:8080/bundle. После чего можно наблюдать магию hot module replacement: если ввести в поле input какой-нибудь текст, переместить курсор на один из символов этого текста, а затем поменять цвет в файле style.css — то цвет фона страницы поменяется практически сразу, при этом не потеряется введенный текст и даже позиция курсора останется прежней.

Хорошая, удобная магия. Но после начала использования возникает много вопросов:

Что это за ./entry?
Что делают и чем отличаются --hot и --inline?
Что это за --module-bind такой?
Почему, если добавить react.js, hot reload перестает работать?

Начнем с самого простого. ./entry и --module-bind — это читерские аргументы, которые позволяют в целях демонстрации запускать webpack без конфигурационного файла webpack.config.js. Первый позиционный аргумент всего лишь имя javascript файла, являющегося «точкой входа» в программу, именно его код будет запускаться при выполнении скомпилированной bundle. Многих разработчиков смущает то, что этот аргумент не выглядит как имя файла. На самом деле это имя файла. Просто в целях экономии символов авторы примера воспользовались одной из особенностей webpack: файлы в require и в командной строке можно указывать без расширения, webpack автоматически попробует найти такой файл .js (или с другими расширениями, если это настроено в конфигурации). Аргумент --module-bind позволяет без конфигурационного файла указать используемые загрузчики, в данном случае для файлов с расширением css будет использован сначала загрузчик css-loader а затем загрузчик style-loader. Как нетрудно догадаться, суффикс -loader тоже можно не указывать, и авторы примера пользуются этим для экономии нескольких символов и запутывания читателей.

На самом деле у webpack три режима работы автоматического обновления страницы. Самый простой режим называется iframe mode: он включается автоматически, если webpack запустить без ключей командной строки --inline и --hot, то есть вот так:

Запущенный веб сервер будет отдавать браузеру следующие страницы:

localhost:8080/webpack-dev-server Покажет меню, в котором можно посмотреть исходик созданной в памяти bundle или открыть в браузере специальную html страницу, единственное назначение которой — выполнить javascript код bundle
localhost:8080/webpack-dev-server/ От предыдущей ссылки отличается присутствием слеша на конце. Список файлов в папке, где запущен сервер. Клик по файлу покажет его в iframe и будет автоматически перезагружать, если файл изменится.
localhost:8080/webpack-dev-server/bundle Та самая страница из первого пункта. Открывается в iframe и автоматически перезагружается. Будет автоматически перезагружаться при изменении любого файла, который приводит к перекомпиляции bundle
localhost:8080/ и localhost:8080/bundle Ловушка для невнимательных. То же что во втором и третьем пункте, но файлы и bundle открываются не в iframe. Перезагружаться не будет. Зачем она? Для второго режима работы, --inline. Зачем показывать в первом режиме работы? Чтобы запутать разработчиков, конечно же. Ну и чтобы раздавать статику без iframe.

Второй режим работы активируется ключом командной строки --inline и предсказуемо называется «inline» режимом. В этом режиме все несколько сложнее: в bundle добавляется модуль «refresh client», исходный код которого можно посмотреть в файле webpack-dev-server/client/index.js. Этот модуль будет загружен с помощью require перед вашим собственным кодом. Более того, если посмотреть в сгенерированный bundle (с помощью меню веб сервера, о котором я писал выше), то можно увидеть что этот require не совсем обычный:

Это результат выполнения вот такого кода:

Этот слабодокументированный синтаксис «webpack resource query» позволяет передавать произвольные параметры в загружаемый через require код. В данном случае webpack-dev-server генерирует bundle, который при загрузке refresh client передает ему адрес запущенного на машине разработчика webpack-dev-server. Зачем ему адрес? Конечно же чтобы подключиться к серверу через socketio и ждать нотификации об изменениях файлов. Получив такую нотификацию, refresh client перезагрузит страницу. По сути происходит то же что и с iframe, но без iframe. Это позволяет отлаживать чувствительный к url код и используется как вспомогательный механизм для третьего, самого интересного режима работы: hot module replacement

Как уже догадался внимательный читатель, третий режим работы включается добавлением ключа командной строки --hot, который возвращает нас к тому заклинанию, с которого началась эта статья. Но здесь не все так просто. «Hot module replacement» — это функциональность webpack, предназначенная не только для быстрой подгрузки изменений на машине разработчика, но и для обновления сайтов в production. При использовании ключа --hot bundle будет собран с поддержкой hot module replacement: соответствующий код и api добавляется в загрузчик webpack, за это отвечает HotModuleReplacementPlugin. Ключ --hot понимает как webpack-dev-server, так и webpack. С помощью hot module replacement api разработчик может запрашивать свой сервер на предмет «а не обновилось ли что», отсылать команду «обновись» дереву модулей и управлять тем, как модули обновляются без перезагрузки страницы.

Здесь два ключевых момента:

Последний вопрос: откуда берется код, который обновляет CSS стили? Как я уже написал выше, webpack сам ничего обновлять не будет и просто вызовет callback, на который может подписаться модуль. Откуда там этот callback? Сюрприз — style-loader имеет встроенную поддержку «hot module replacement». Специально для того, чтобы работал пример из документации.

Когда я меняю свои файлы во время работы webpack-dev-server, файлы пакета не обновляются. Вот мои файлы webpack.config.js и package.json, как вы можете видеть из моего сценария npm, я решил запустить webpack watch и webpack-dev-server в одной команде ( npm run watch & webpack-dev-server --content-base ./ --port 9966 ) :

Моя структура каталогов:

Каждый файл внутри каталога assets генерируется webpack

Вам нужно запустить webpack-dev-server с флагом --hot:

webpack-dev-server --content-base ./ --port 9966 --hot

Затем вы можете получить доступ к версии с горячей загрузкой localhost: 9966 / webpack-dev-server /

Вам также не нужно запускать часы.

Обновить:

Эта запись в конфигурации вашего веб-пакета должна измениться:

entry: ['./js/main.js'], -> entry: ['webpack/hot/dev-server' , './js/main.js']

Измените запись publicPath:

В моем случае ошибка была вызвана пустым пространством в имени каталога, при изменении «Repository Name» на «RepositoryName» все работало нормально!

Я положу это сюда на всякий случай, если это кому-то поможет. Моя проблема была той же, но вызвана несогласованным использованием заглавных букв в именах каталогов и объявлении псевдонима webpack.

У меня был каталог WebGL , на который я ссылался в своих псевдонимах как webgl , и, к сожалению, это сработало для сборки, но не сработало для отслеживания кода.

@funkybunky определил правильную проблему, но (IMHO) исправил ее неправильно. По крайней мере, в моем случае webpack пытался отслеживать каждый используемый им файл, включая глубокую цепочку из тысяч файлов зависимостей, извлеченных из npm . Я добавил это в свою конфигурацию, согласно документации:

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

Чтобы заставить webpack наблюдать за изменениями моих файлов (Ubuntu 14.04), мне пришлось увеличить количество наблюдателей (раньше я увеличивал это число, но оно все еще было слишком низким):

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Сначала я подозревал, что причина в fsevents , которая не работает в Ubuntu, но, очевидно, это не так.

Кроме того, поскольку теперь просмотр и повторная компиляция работали, но часть автоматического обновления браузера не работала, я добавил параметр --inline к ответу @deowk, который включает «встроенный режим»: webpack-dev-server --content-base ./ --port 9966 --hot --inline

Webpack — это инструмент, позволяющий скомпилировать, например, JavaScript модули в единый JS-файл. Webpack также известен как сборщик модулей.

При большом количестве файлов он создает один объемный файл (или несколько файлов) для запуска вашего приложения.

Он также способен выполнять множество иных операций:

помогает собрать воедино ваши ресурсы
следит за изменениями и повторно выполняет задачи
может выполнить транспиляцию JavaScript следующего поколения до более старого стандарта JavaScript (ES5) с помощью Babel, что позволит использовать новейшие функции JavaScript, не беспокоясь о том, поддерживает их браузер или нет
может выполнить транспиляцию CoffeeScript в JavaScript
может конвертировать встроенные изображения в data:URI
позволяет использовать require() для CSS файлов
может запустить webpack-dev-server (в нём встроен локальный сервер и livereload (“живая перезагрузка браузера”))
может работать с Hot Module Replacement (замена горячего модуля)
может разделить выходной файл (output file) на несколько файлов, чтобы избежать медленной загрузки страницы из-за большого размера JS-файла
может выполнить Tree Shaking

Webpack не ограничивается одним лишь фронтендом, его также успешно применяют в бэкенд разработке на Node.js.

У Webpack есть предшественники, у которых он перенял многие идеи. Основное различие заключается в том, что те инструменты известны как task runners (такс-раннеры), в то время как Webpack ничто иное, как сборщик модулей.

Webpack — э т о более целенаправленный инструмент. Вам достаточно указать точку входа в ваше приложение (это может быть даже HTML-файл с тегами <script>), а webpack проанализирует файлы и объединит их в один выходной JavaScript-файл, содержащий все необходимое для запуска приложения.

Webpack может быть установлен глобально или локально для каждого проекта.

Глобальная установка

Глобальная установка с помощью Yarn:

Теперь мы можем запустить webpack:

Локальная установка

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

Установка с помощью Yarn:

После этого добавьте эти строчки в свой package.json файл:

Как только все будет сделано, вы можете запустить Webpack, набрав:

в корневом каталоге проекта.

По умолчанию, Webpack (начиная с 4-й версии) не требует никакой настройки, если вы соблюдаете эти правила:

точкой входа вашего приложения является ./src/index.js
вывод (output) размещается в ./dist/main.js
Webpack работает в production mode (режим производства)

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

Точка входа

По умолчанию, точкой входа является ./src/index.js . Нижеприведенный пример использует файл ./index.js в качестве входной точки.

Вывод (output)

По умолчанию, вывод размещается в ./dist/main.js . В нижеприведенном примере, результат работы в Webpack генерируется в файле app.js :

С помощью Webpack можно использовать оператор import или require в своем JavaScript коде для того, чтобы подключать файлы любого типа (например, CSS).

В Webpack загрузчики являются аналогами задач (tasks) в Grunt и Gulp. Они принимают содержимое файлов, а затем преобразуют его необходимым образом и включают результат преобразования в общую сборку. Например, они могут компилировать TypeScript, загружать компоненты Vue.js и многое другое.

Например, в своем коде вы можете использовать:

указав конфигурацию данного загрузчика в файле webpack.config.js :

Регулярное выражение применяет данный загрузчик только к CSS файлам.

У загрузчика есть параметры:

Для одной и той же задачи может потребоваться несколько загрузчиков:

Порядок выполнения перевернут (последнее выполняется первым).

Так сколько всего существует загрузчиков? Очень много! Здесь вы сможете найти полный список.

Самым часто используемым загрузчиком является Babel — он используется для транспиляции современного JavaScript в ES5:

Данный пример заставляет Babel предварительно обрабатывать все наши React/JSX файлы:

Здесь вы можете увидеть параметры babel-loader .

Плагины — это почти то же самое, что и загрузчики, но под стероидами. Они могут сделать то, что не могут загрузчики. Ко всему прочему, Webpack построен на системе плагинов, которые вы используете в своем файле конфигурации.

Рассмотрим следующий пример:

Плагин HTMLWebpackPlugin автоматически создает HTML-файл с уже подключенным скриптом.

Здесь доступно множество плагинов.

Еще один полезный плагин, CleanWebpackPlugin , мы можем использовать перед перегенерацией файлов, чтобы очистить нашу папку dist/ и получить аккуратный файл с конфигурацией.

Данные режимы (появившиеся в 4-й версии Webpack) настраивают среду, в которой будет работать Webpack. Режим может быть настроен на development или production (по умолчанию стоит production ).

Режим production работает медленнее, чем development , так как ему нужно создать более оптимизированный бандл. Полученный JavaScript файл меньше по размеру, поскольку многое из режима development в нем отсутствует.

Webpack является одним из самых мощных и гибких инструментов для сборки frontend. Она содержит основные понятия, однако для начала их будет достаточно.

Инструменты сборки стали неотъемлемой частью веб-разработки, в основном из-за возрастающей сложности JS-приложений. Бандлеры позволяют нам упаковывать, компилировать, организовывать множество ресурсов и библиотек, необходимых для современного веб-проекта.
В этом гайде будет рассмотрен webpack, мощный бандлер с открытым исходным кодом, который может обрабатывать огромное количество различных задач. Автор статьи покажет вам как писать модули, бандл код, использовать некоторые плагины загрузчика. Пособие подойдет для тех, кто только начинает изучать этот инструмент, однако уже имеет некоторые знания JS.

Как и во многих других аспектах веб-разработки, здесь нет стандартного набора инструментов, который нужно использовать. Прямо сейчас разработчики могут выбирать между webpack, Gulp, Browserify, NPM scripts, Grunt и еще десятком других. Можно, конечно, провести их глубокое сравнение, но в целом все эти инструменты очень похожи, поэтому чаще всего дело сводится к личным предпочтениям и типу проекта, над которым вы работаете.
Тут некоторые плюсы и минусы, которые помогут вам решить, подходит ли этот бандлер именно вам:

Великолепен для работы с одностраничными приложениями
Воспринимает как require()- так и import-синтаксисы модуля
Позволяет осуществлять продвинутое разделение кода для более быстрой разработки с помощью React, Vue.js и подобных фреймворков
Наиболее популярный инструмент разработки по версии обзора JS в 2016 году

Не подойдет для новичков
Работа с файлами CSS, картинками и другими не JS ресурсами по началу сбивает с толку
Документация могла бы быть лучше
Очень много изменений, большинство гайдов 2016 уже устарели

Самый простой способ установки это использовать менеджер пакетов. Мы будем пользоваться npm, но вы можете использовать Yarn или любую другую альтернативу. В обоих случаях вам нужно иметь Node.js и готовый к работе package .json на компьютере.
Предпочтительнее устанавливать его локально без тега –g . Это поможет каждому, кто работает над вашим проектом, быть уверенным в том, что у вас одна и та же версия webpack’a.

После того как вы установили бандлер, лучше всего запустить его с помощью скрипта Node.js. Добавьте эти строки в ваш package.json.

Теперь с помощью вызова npm run build из командной строки мы можем сделать webpack bundle нашими файлами ( -р означает создание и уменьшает связанный код). С запуском npm run watch начнется процесс, который автоматически свяжет наши файлы в случае изменения любого из них.
Последняя часть нашей настройки — это указать webpack, какие файлы связывать. Рекомендуем сделать это путем создания config файла.

Здесь мы рассмотрим файл конфигурации в его самой базовой форме, но не позволяйте ему вас провести- файл конфигурации webpack достаточно мощный, довольно сильно различается от проекта к проекту и в некоторых случаях может стать ну очень сложным.

В корневой директории вашего проекта добавьте файл webpack.config.js.

webpack.config.js

entry указывает webpack’y, какой из JavaScript файлов является основным. Существует множество различных стратегий настройки входных точек, но в большинстве случаев достаточно одной записи. В output мы указываем имя нашего пакета и путь к нему. После запуска webpack мы получим весь наш JavaScript в файле bundle.js. Это единственный файл, который мы будем связывать в нашем HTML:

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

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

Мы хотим добавить модуль, который приветствует наших пользователей. Мы создаем файл greeter.js и экспортируем простую функцию.

Чтобы использовать этот модуль, мы должны импортировать его и вызвать его в нашей точке входа, которым является, если вы посмотрите на файл конфигурации, - index.js.

Теперь, когда мы запускаем bundler с npm run build и открываем наш HTML в браузере, мы видим следующее:

Наша точка входа и наш модуль greeter были скомпилированы в один файл, называемый bundle.js, и он был выполнен браузером. Вот простая схема того, что происходит на данный момент:

Мы хотим, чтобы наше приложение указывало, в какой день недели он встречает пользователей. Для этого мы будем использовать moment.js, импортируя его непосредственно в наш модуль greeter.
Сначала мы должны установить библиотеку через npm:

Затем в нашем модуле приветствия мы просто импортируем библиотеку точно так же, как мы импортировали локальные модули в предыдущую точку:

Наша блок-схема теперь выглядит так:

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

Загрузчики - это способ webpack выполнять задачи во время компоновки и до или после обработки файлов каким-либо образом. Например, они могут компилировать TypeScript, загружать компоненты Vue.js, отображать шаблоны и многое другое. Большинство загрузчиков написаны сообществом, поскольку список популярных загрузчиков можно посмотреть здесь.
Предположим, мы хотим добавить линтер к нашему проекту, который проверяет наш код JS на наличие ошибок. Мы можем это сделать, включив загрузчик JSHint, который будет перехватывать все виды плохого кода.
Сначала нам нужно установить JSHint и загрузчик webpack JSHint:

Теперь мы собираемся добавить несколько строк в наш файл конфигурации webpack. Это инициализирует загрузчик, сообщает ему, какие типы файлов следует проверять, а какие - игнорировать.

webpack.config.js

Теперь, когда webpack запущен, он покажет нам список предупреждений в терминале (которые мы проигнорируем):

Поскольку moment.js находится в папке node_modules, он не будет линтирован загрузчиком JSHint:

На этом мы заканчиваем наше знакомство с webpack! Поскольку это урок для новичков, мы попытались охватить только самые полезные и обязательные концепции инструмента. Мы надеемся, что руководство было полезным, не слишком запутывающим, и, исходя из названия, займет 15 минут.
В ближайшем будущем автор планирует добавить вторую часть к этому учебному пособию, объясняя, как работать с модулями CSS и другими более продвинутыми функциями. Тем временем, если вы хотите больше узнать о webpack (и есть намного больше), он рекомендует проверить эти потрясающие ресурсы:

Читайте также: