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

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

Но эта теория не соответствует реальности современной веб-разработки. Учитывая все, что мы можем делать внутри браузера, веб-проекты сейчас сложнее, чем когда-либо. Это означает, что предоставление неизмененных исходных файлов является медвежьей услугой для ваших посетителей. Часто бывает лучше не просто объединять файлы вместе, но и предварительно обрабатывать их для выполнения определенных оптимизаций, которые были бы громоздкими или занимали бы много времени, если бы выполнялись в процессе разработки. Добавление поддержки старых браузеров, сжатие ресурсов, объединение файлов, удаление неиспользуемого кода, проверка вашего кода на соответствие более строгому анализу и многое другое: все эти шаги лучше выполнять на компьютере, а не на самих разработчиках.

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

Комплектация не является чем-то новым. Тем не менее, я думаю, что мы находимся в точке, когда наше понимание того, что такое хорошее веб-бандлинг, несколько меняется.

Раньше я думал об объединении (или компиляции, или транспиляции, или оптимизации, или любом количестве различных описаний) веб-сайта как о простом процессе оптимизации для отдельных типов ресурсов. Что-то вроде этого:

В результате я использовал несколько различных инструментов, которые помогли мне объединить мои веб-проекты. Все началось с Grunt, который, что характерно, не совсем сборщик, а таскраннер. Это означает, что он выполняет определенные отдельные задачи при создании веб-сайта. В этом смысле такие вещи, как сжатие изображений, — это задача; транспиляция JavaScript — другая задача; и так далее и тому подобное.

Через некоторое время я переключился на Gulp. Мне это понравилось намного больше, чем Grunt; возможность создавать линейные задачи с использованием стандартного кода JavaScript сделала его отличной заменой зачастую запутанным задачам и плагинам Grunt, основанным на конфигурации. Но он по-прежнему следовал идее запуска задач, то есть наличия разных маршрутов, по которым должны пройти ресурсы вашего сайта, прежде чем он будет собран.

Только когда я начал использовать Browserify, а позже Webpack, я понял, что все понял неправильно. Создание веб-сайта не должно выполняться последовательностью отдельных задач; это должна быть одна задача. Что-то вроде этого:

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

По иронии судьбы, я возвращался из Gulp — инструмента, который я до сих пор люблю — обратно к чудовищному конфигурационному файлу в стиле Grunt. Но я хотел посмотреть, о чем идет речь.

Несколько видеороликов также помогли мне получить его. Это один из них:

Магия Webpack не в том, что он лучше справляется с задачами. Черт, вы не можете использовать его для произвольных задач. Вместо этого он отлично справляется с одной задачей — комплектованием. Это достигается за счет подхода более высокого уровня к тому, что представляет собой веб-приложение. Внезапно вы не рассматриваете свой код, стили и другие ресурсы как отдельные объекты; они являются частью одного и того же волшебного, загадочного супа, который смешивается вместе, чтобы создать хорошо сбалансированный веб-сайт.

Рассмотрим эти примеры. Раньше я писал файлы CSS, используя Less. Less поддерживает (через Gulp) большое количество плагинов для минимизации, автоматического добавления префиксов и любого количества задач, которые вам могут понадобиться для запуска на вашем CSS. Но он по-прежнему рассматривается как отдельная сущность от файлов изображений, которые он использует, или HTML-файлов, в которых он используется. HTML, используя имя файла, которое, как я знал, будет местом расположения моих окончательных скомпилированных файлов. Затем, конечно, мне понадобилась отдельная задача, чтобы просто скопировать файлы изображений, на которые есть ссылки, в правильное место назначения.

В Webpack все является модулем, поэтому мой CSS просто ссылается на файлы, используя их существующее (локальное) имя пути. При объединении Webpack автоматически идентифицирует эти ресурсы как необходимые, обработает их так, как я хочу, переместит их в конечный пункт назначения и при необходимости изменит ссылки на пути к файлам. Это более целостный взгляд на это.

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

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

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

По сути, большая часть догадок о ссылках на файлы берется из работы разработчика и обрабатывается сборщиком. Файл отсутствует? Webpack выдаст вам сообщение об ошибке. Файл не указан и как таковой не нужен? Он не будет включен в комплект.

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

В моих личных тестах проекта результаты не могли быть лучше, как в процессе разработки, так и в конечном результате. Окончательные файлы упакованы настолько плотно, насколько это возможно: небольшие изображения встроены в код, таблицы стилей или HTML; все оптимизации (включая оптимизацию изображений) выполняются во время сборки; как автоматическое префиксирование CSS, так и автоматическое полизаполнение кода (в зависимости от целевых поддерживаемых браузеров) выполняются автоматически; и структура проекта настолько высока, насколько это возможно.

Webpack — это не просто еще один инструмент для разработки JavaScript, это более зрелый способ взглянуть на то, как мы эффективно создаем веб-сайты. Неудивительно, что новички, такие как FuseBox, следуют по стопам концепций, начатых Webpack.