Сложная система сборки

Сначала создайте его, затем улучшите и, наконец, оптимизируйте.

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

Прошел год с момента выпуска нового пользовательского интерфейса на yfret.com, и наша кодовая база значительно выросла. Мы используем react, backbone, j Query и целый ряд новых библиотек по мере необходимости. Как и следовало ожидать, кодовая база начала расти, и управление нашими сборками для производства стало труднее. Очистка кеша, объединение файлов, фрагментация выполнялись вручную. Нам нужно было решение, чтобы внешний интерфейс оставался в здравом уме и простым в обслуживании. Так началось наше путешествие по пересмотру нашей системы сборки и наших потребностей в целом.

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

Технический анализ:

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

Что мы хотели сделать?

  • Простота объединения файлов
  • Простота обработки пакетов и их обновления
  • Простота обработки кеша: только одно объединяет обновления кеша, а не перезагружает все приложение.
  • Простота использования функций Es6, не беспокоясь о поддержке браузера.

Поиск решения:

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

Огромное спасибо Артёму Тритяку за подробный пост о переходе с Requirejs на webpack. Это очень помогло мне быстро двигаться вперед.



Помимо упомянутых Артёмом Тритяком причин перехода на вебпак, вот ещё несколько, на которые я мог бы указать.

  • Я вручную собирал файлы вместе и должен был сам позаботиться о группировке файлов. Обработка зависимостей была непростой, и я мог только связать файлы поставщиков
  • С помощью веб-пакета добавление зависимостей было простым. npm может позаботиться обо всех зависимостях, и все, от CSS до js, загружается как модули. В Requirejs мне пришлось вручную добавить css в мой файл HTML, а файлы js были загружены с помощью require. Обычно я создавал для него прокладку.
  • Для обработки кеша у меня была глобальная очистка кеша require.config, поэтому даже небольшое изменение файла приводило к сборке и обновлению всего приложения. Webpack может сделать это, просто создав другую контрольную сумму md5 для этого пакета.
  • Лучшее обслуживание глобальных переменных, чтобы убедиться, что ничего не выставлено глобально по ошибке.
  • Так много плагинов в webpack могут облегчить жизнь в поддержке кода. Такие вещи, как eslinting, препроцессоры css, пресеты babel для поддержки функций es6 — все это можно легко добавить.
  • Поскольку css также загружается как модули, становится легче рассуждать, а также предотвращается загрязнение css, принадлежащего некоторым другим компонентам.
  • Обновление до более новых версий библиотек стало проще.

Понимание Webpack:

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

Быстрый поиск веб-пакета на YouTube может привести к действительно хорошим учебникам, достаточным для того, чтобы вы могли начать с основ.

Вот несколько видео от LearnCode.Academy и Traversy Medi, которые помогут вам начать работу.

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



Переход к расширенному режиму:

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

Теперь ваши цели будут включать:

  • Разделение кода
  • Иметь возможность анализировать созданные пакеты
  • Оптимизируйте созданные пакеты для достижения максимальной эффективности.
  • Имейте отдельные сборки для производства и разработки.

У Адама Рэкиса есть очень хороший пост, который может указать вам правильный путь для создания сложных настроек.



Как только вы закончите с разделением кода и созданием производственных сборок, вы еще не закончили.

Теперь ваши цели будут развиваться, чтобы справиться со следующими вещами:

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

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



Если вы дочитали до этого момента, похлопайте себя по спине, вы хорошо поработали.

Общие проблемы, с которыми я столкнулся при переходе на веб-пакет:

  • Я почему-то не мог заставить работать webpack 3. Он не создавал пакеты специально для асинхронных модулей, поэтому вместо этого я перешел на webpack 2. Если вы знаете решение, пожалуйста, напишите его в разделе комментариев.
  • Мне потребовалось некоторое время, чтобы разобраться с загрузчиками и как их использовать.
  • Потребовалось время, чтобы понять долгосрочное кэширование. Были некоторые проблемы с плагинами манифеста. Наконец, я использовал плагин inlinewebpackmanifest.
  • Не удалось заставить Google диаграммы работать, поэтому я загружаю их отдельно через тег скрипта в нашем базовом HTML-шаблоне.

Наша окончательная конфигурация Webpack:

Сначала это может показаться сложным, но как только вы это поймете, это может быть довольно легко.

Вывод:

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

Я что-то пропустил?

Дайте мне знать ваши комментарии и предложения.

Хотите узнать больше о YFret?

Наша миссия в YFret (Why Fret) — использовать элегантное программирование и надежные технологии для создания суперинтеллектуального лучшего друга маркетолога. Представьте себе опытного маркетолога электронной коммерции с лучшим другом в области технологий, который может упростить его жизнь в качестве маркетолога, ориентированного на данные. Перейдите здесь, чтобы узнать больше.

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

Подробнее о моих блогах читайте здесь.