TL;DR

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

Семенной проект

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



IdanCo / webpack-modular
webpack-modular - проект каркаса, демонстрирующий модульное, простое и эффективное использование webpack и npm во внешнем интерфейсе… github.com



Предисловие: Что такое веб-пакет?

Если вы уже знакомы с webpack, переходите к следующей части.

Распространенной ошибкой при представлении webpack является попытка поместить его где-нибудь между знакомыми нам инструментами, такими как gulp, grunt, bower и т. Д. Но webpack - это больше, чем просто инструмент, это архитектура проекта , который требует времени и терпения, чтобы полностью понять. Я начну с небольшой строчки кода, обычно встречающейся в файлах index.js, которая всегда настраивает меня на настроение веб-пакета -

Я предполагаю, что вы уже знакомы с import в ES6, но то, что волнует каждого разработчика javascript, конечно же, style.css. Как вы можете импортировать файл CSS в файл JS? Это мерзость!

Ну, ты не можешь. Ни один живой браузер не может скомпилировать этот код. Но никому не следует: прежде чем этот код попадет в браузер, веб-пакет объединит его.

Давайте остановимся на минутку и поразмышляем над этим: большинство инструментов сборки так или иначе манипулируют нашим кодом (concat, transpile и т. Д.), Но это все тот же код, работающий в браузере клиента. Webpack, с другой стороны, перестраивает наш код в пакет на основе этого импорта. посмотрим, как это делается.

ЭТАП 1: Точка входа

В процессе связывания webpack анализирует ваш проект, начиная с файла, определенного как запись в вашей конфигурации webpack:

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

  • В пакет входят только ресурсы, которые вы действительно используете
  • Больше не нужно сканировать папки и объединять массовые файлы
  • Ресурсы всегда загружаются в том порядке, в котором они необходимы
  • Общие фрагменты кода могут быть сгруппированы вместе

ЭТАП 2: Погрузчики

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

Обратите внимание, что test задает типы файлов, к которым будет применяться это правило. Затем в разделе использование мы определяем набор загрузчиков, которые будут применяться к файлам, соответствующим тесту. Обратите внимание, что загрузчик применяются в обратном порядке. Таким образом, в приведенном выше случае файлы, соответствующие регулярному выражению /<▪\.сначала будут преобразованы в модули javascript, а во-вторых быть введенным на страницу.

Но на какой странице? Что ж, это просто, должен быть только один - index.html. Webpack был разработан для SPA (одностраничных приложений).

ЭТАП 3: Плагины

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

Другие распространенные действия, выполняемые надстройками:

  • Внедрение ресурсов в index.html
  • Разделить код между фрагментами поставщика (angular, jquery и т. Д.) И фрагментами приложения
  • Очистите папку dist перед сборкой
  • И многое другое ...

ЭТАП 4: Вывод

Последним в нашем списке идет вывод. Выход устанавливает целевую папку для окончательного результата пакета:

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

Начало

Если вы пропустили предисловие, продолжайте здесь.

Создание собственного диспетчера задач

Поскольку мы не хотим полагаться на слишком много разных технологий, мы откажемся от grunt, gulp и всех этих других диспетчеров задач. Остается вопрос - как мы собираемся выполнять все наши различные задачи? Нам все еще нужна задача для сборки, тестирования, обслуживания и так далее. Ответ: мы просто будем использовать скрипты npm. Просто чтобы почувствовать это, добавьте это в свой package.json -

и из типа корневой папки проекта -

npm run tryme

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

К счастью, webpack также имеет очень сильный api node.js. Итак, как предлагается в этой замечательной статье, мы можем просто передать всю логику в отдельный файл узла и использовать сценарий npm для его запуска. Нравится -

Проблема с этим подходом заключается в том, что вы можете получить несколько файлов node.js для каждой задачи (build.js, serve.js и т. Д.), Многие из которых выполняют очень похожие задачи. Поэтому я предлагаю продвинуть этот подход еще на один шаг и удалить всю логику из package.json и переместить ее в новый файл с именем tasks.js, реализовав событие жизненного цикла NPM . Эта изящная маленькая переменная позволяет вам точно знать, какая команда npm инициировала текущий процесс, поэтому вам больше не нужно package.json, чтобы указывать на нужный файл.

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

И этот новый файл tasks.js будет выглядеть примерно так:

Построение задач

Итак, теперь, когда мы создали собственный персональный диспетчер задач, пришло время создавать сами задачи. мой выглядит примерно так -

Здесь мы видим два метода: serve и build. Оба инициируют компилятор, передавая файл конфигурации веб-пакета (строки № 18 и № 26). Но потом расходятся:

  • Метод serve передает компилятор в экземпляр webpackDevServer (# 19), а затем запускает его (# 21).
  • Метод build просто запускает компилятор (# 28).

Различные конфигурации для разных задач

Некоторые из вас, возможно, заметили, что и serve, и build используют один и тот же файл конфигурации webpack (№2). Не нужно быть экспертом по веб-пакетам, чтобы догадаться, что для этих задач требуются разные конфигурации. Возьмем, к примеру, минимизацию и углификацию: вы не хотите, чтобы в вашей среде разработки был нечитаемый JS, и вы не хотите, чтобы в производственной среде загружались большие неминифицированные JS. Итак, как мы можем добиться этого разделения, не слишком усложняя наш файл задач?

Давайте посмотрим на ./webpack.config.js:

Как видите, этот файл на самом деле не содержит никакой собственной конфигурации, а скорее проксирует соответствующий файл конфигурации из папки conf в соответствии с текущим событием npm. На самом деле этот переключатель можно легко разместить внутри t asks.js, но наличие файла webpack.config.js в корневой папке вашего проекта - хорошее соглашение, которое стоит сохранить: он позволяет люди знают, что ваш проект использует webpack.

Модульная конфигурация

Итак, мы уже установили, что для разных задач требуются разные конфигурации. Но что еще более важно, даже разные конфигурации имеют много общего. Возьмем, к примеру, транспиляцию файлов JS: и serve, и build требуют babel loader. Итак, как вы можете использовать общий код для разных конфигураций веб-пакетов? Здесь в игру вступают такие инструменты, как webpack-config и webpack-merge: они позволяют нам переработать некоторую базовую конфигурацию и повторно использовать ее, добавляя, удаляя или изменяя определенные части.

Эта практика позволяет нам иметь один файл, назовем его webpack. base .config.js,, который содержит конфигурацию, общую для всех задач, и многие другие файлы для конкретных задач, например webpack. build .config.js и webpack. serve .config.js

Вот упрощенные версии base и build с использованием webpack-config (для полной настройки ознакомьтесь с примером проекта):

Обратите внимание, как в webpack. build .config.js мы вызываем базовую конфигурацию (строка № 6) и объединяем ее с конкретными задачами, уникальными для Конфигурация сборки, например:

ProTips

Вот несколько советов, как максимально использовать эту архитектуру:

Общий файл конфигурации

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

Оформить заказ на полную версию в примере проекта.

ExtractTextPlugin

ExtractTextPlugin требует немного другого подхода, чтобы заставить его работать в модульной архитектуре. Этот плагин используется для извлечения CSS в отдельный файл, вместо того, чтобы вставлять его в заголовок. Поскольку его синтаксис является оболочкой для правила, на которое он ссылается (обычно. css или. scss), его немного сложнее использовать повторно. К счастью, у него есть переключатель включения / выключения и резервное правило, которые в совокупности делают его полностью модульным. Итак, базовая конфигурация может выглядеть так -

А теперь, если мы хотим отключить этот модуль для сервера разработки (потому что он не работает с перезагрузкой в ​​реальном времени), мы можем просто добавить эти строки в конфигурацию serve. -

В сборке дистрибутива мы определенно хотим включить ее, поэтому в конфигурации сборки мы могли бы добавить это:

Резюме

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

  • Иди на пляж
  • Работайте над своим сторонним проектом
  • Пишите статьи на Medium

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