Для тех из вас, кто никогда не слышал о Webpack, это сборщик модулей. Говоря простым языком: инструмент, используемый для объединения ресурсов, сценариев и стилей. Согласно веб-сайту Webpack, Webpack состоит из 4 основных компонентов: Entry, Output, Loaders и Plugins
- Запись — это точка входа для создания того, что команда Webpack называет графом зависимостей. Думайте о графе зависимостей как о списке файлов, которые необходимы вашему приложению для работы.
- Вывод просто определяет, где формируется ваш пакет.
- Загрузчики — это модули, которые вы устанавливаете для передачи определенных файлов для предварительной обработки перед компиляцией пакета. Например, чтобы преобразовать файлы TypeScript в JavaScript, нам нужно установить
ts-loader
и создать правило для загрузки файлов с расширением.ts
вts-loader
для предварительной обработки. - Плагины работают там, где не работают загрузчики. У них есть доступ ко всему жизненному циклу компиляции, что делает их одним из наиболее важных компонентов Webpack. Изучение плагинов и выяснение того, как их использовать для создания наиболее оптимизированного и эффективного пакета, займет большую часть вашего времени.
Теперь немного предыстории миграции:
Я использую комбинацию PHP (Silex/Symfony) и JavaScript (ES5) для создания наших офисных веб-приложений. Мне было поручено перенести наш текущий процесс сборки с Gulp на Webpack по следующим причинам:
- Уменьшите сложность, сократив вдвое количество devDependencies
- Используйте зависимости, используя ES6 (да, я знаю, что gulp тоже может это сделать)
- Упрощение процесса сборки
Путешествие было немного трудным, но вот несколько вещей, которые я усвоил при переносе внешнего интерфейса веб-приложения PHP на Webpack 2:
При использовании Font Awesome создайте переменную, указывающую на каталог шрифтов.
Итак, первое, что я сделал сразу же, это собрал все в один файл (конечно, поскольку это то, что Webpack делает лучше всего). Мне удалось поместить большинство скриптов в один файл bundle.js, а стили — в файл bundle.css, но я заметил, что шрифт awesome не работает. После долгих копаний я нашел быстрое решение своей проблемы:
Я заметил, что каталог fonts отсутствует в font-awesome, в котором содержится все великолепие font-awesome (хе-хе). Включение пути к каталогу шрифтов в виде переменной позволит Webpack найти и связать все шрифты в font-awesome.
Используете шаблонизатор типа Twig? Возможно, вам придется использовать expose-loader
jQuery присутствует практически во всех наших шаблонах Twig в виде тега скрипта где-то в шаблоне. Поскольку шаблоны Twig обрабатываются на стороне сервера, немедленно вызывается функция jQuery, которая заключает весь код этого шаблона в тег script. Этот немедленный вызов означает, что именно в этот момент jQuery необходимо определить в глобальной области видимости, прежде чем эта функция запустится, иначе она завершится ошибкой. Здесь в игру вступает expose-loader. Что сделает expose-loader, так это выставит переменную (переменные) в глобальную область/объект. Вот пример использования expose-loader:
Согласно документации NodeJS для метода разрешения, «[он] использует внутренний механизм require() для поиска местоположения модуля, но вместо загрузки модуля просто возвращает разрешенное имя файла». В этом случае мы получаем путь к jquery
, который должен вести к node_modules
. Поэтому, если мы загрузим этот rules
array в свойство modules конфигурации веб-пакета, создадим и обновим страницу, у нас должен быть глобальный доступ к jQuery, используя любой из вышеуказанных параметров.
Используйте NODE_ENV
, чтобы лучше контролировать производственную среду
Я позволю сути говорить больше всего:
Итак, здесь у нас есть production
, которое является логическим значением, определяющим, является ли значение NODE_ENV
производственным. Это полезно тем, что теперь у нас больше контроля над тем, что происходит с нашей производственной средой. Мы можем дать нашим пакетам определенное имя и/или местоположение в зависимости от строительных лесов проекта. Мы также можем добавить определенные плагины прямо в конфигурацию, если мы запустим процесс сборки. Кроме того, использование DefinePlugin
установит значение process.env.NODE_ENV
во время компиляции. Возможно, есть более (умные) способы использования production
, но вот два бесплатных способа :)
Используете sass-loader? Если это так, обязательно определите свой стиль вывода.
Мы столкнулись с определенной проблемой в sass-loader при использовании цветов в именах классов. Например, .header-blue
будет интерпретироваться sass-loader как .header-#0000ff
.
Хорошо, да, я понимаю. Использование имен цветов при определении классов или идентификаторов — ужасный способ именования, но это случается с лучшими из нас. Чтобы избежать этой головной боли, все, что нам нужно сделать, это предоставить sass-loader параметр outputStyle: 'uncompressed’
, и он должен работать, как задумано.
Хотите еще больше сжать момент? Попробуйте игнорировать локали
Некоторые люди хотят иметь абсолютный минимум зависимостей, чтобы сделать свое веб-приложение или веб-сайт более производительным. Если вам требуется/импортируется момент и вам не нужны файлы локалей, которые сопровождают его, попробуйте игнорировать локали следующим образом:
IgnorePlugin
, похоже, не описан в документации Webpack 2, но он работает и описан в документации Webpack 1 и вики в репозитории Webpack. Требуется регулярное выражение для проверки запрошенного каталога (он сообщит веб-пакету игнорировать/не связывать любой файл/каталог, который охватывает ваше регулярное выражение) в качестве первого аргумента, а второй аргумент — это другое регулярное выражение, соответствующее запрошенному каталогу. Кроме того, регулярное выражение второго аргумента должно соответствовать каталогу.
Вывод
Поэтому, даже пройдя через все это, я обнаружил, что размеры наших пакетов все еще немного больше, чем когда мы использовали Gulp. Я смог еще больше уменьшить размеры пакета, импортировав уже минимизированные файлы зависимостей, которые затем были дополнительно минимизированы Webpack для создания пакета. Моя первоначальная мысль об этом заключалась в том, что это сломает приложение, учитывая, что я минимизирую уже минифицированные файлы вместе, но, к моему удивлению, приложение было быстрее, и все работало отлично. Это может быть связано с тем, как Webpack минимизирует свои активы или с созданием графа зависимостей.
Я настоятельно рекомендую изучить, как использовать такой инструмент, как Webpack, для расширения знаний в области веб-разработки, но, пожалуйста, предварительно изучите информацию, прежде чем выполнять миграцию. Webpack было сложно внедрить для приложения, над которым я работаю, и, возможно, было бы быстрее придерживаться Gulp и просто добавить его в gulpfile. Я вижу преимущество более легкого для чтения и понимания файла webpack.config.js по сравнению с постоянно расширяющимся гигантским файлом gulpfile.js.
Я знаю, что, вероятно, можно сделать больше улучшений, чтобы сделать наши пакеты меньше и оптимизировать их. Поскольку я все еще новичок в Webpack, я еще не разбираюсь в таких улучшениях. Я бы хотел, чтобы команда Webpack сделала так, чтобы их документация охватывала больше вариантов использования с большим количеством (обновленных) примеров, включающих их плагины, и, возможно, с большим количеством объяснений лучших практик. Я потратил больше времени на поиск ответов в системе отслеживания проблем Webpack, чем на их документации. В конце концов, Webpack — это фантастический инструмент, которым сложно овладеть.