Для тех из вас, кто никогда не слышал о 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 — это фантастический инструмент, которым сложно овладеть.