Выбирайте и настраивайте инструменты сборки на основе лучших практик.
Сегодня web.dev запускает новую инициативу под названиемtooling.report . Это веб-сайт, который дает веб-разработчикам обзор функций, поддерживаемых различными популярными инструментами сборки. Мы создали этот сайт, чтобы помочь вам выбрать правильный инструмент сборки для вашего следующего проекта, решить, стоит ли переход от одного инструмента к другому, или выяснить, как внедрить лучшие практики в конфигурацию вашего инструмента и базу кода. Инструменты имеют разные области применения и удовлетворяют разный набор потребностей, а это означает, что выбор и настройка инструментов требует компромиссов. С помощьюtooling.report мы стремимся объяснить эти компромиссы и документировать, как следовать лучшим практикам с любым конкретным инструментом сборки.
Звучит захватывающе? Посетитеtooling.report, чтобы начать изучение, или читайте дальше, чтобы узнать больше о том, почему и как мы разработали этот сайт.
Инструменты сборки часто мешают нам
В GoogleChromeLabs мы создали веб-приложения, такие как Squoosh и Proxx , а также веб-сайты, подобные сайту Chrome Dev Summit 2019 . Как и в любом проекте веб-разработки, мы обычно начинаем с обсуждения инфраструктуры проекта, такой как среда хостинга, фреймворки и настройка нашего инструмента сборки. Эта инфраструктура обновляется по мере развития проекта: добавляются новые плагины, чтобы соответствовать используемым нами платформам или методам, или меняется способ написания кода, чтобы наши инструменты сборки лучше понимали, чего мы пытаемся достичь. На протяжении всего этого процесса мы часто обнаруживали, что выбранные нами инструменты в конечном итоге мешают нам.
Наша команда сосредоточена на том, чтобы предоставить пользователям лучший опыт работы в Интернете, что часто приводит к тонкой настройке того, как собираются и доставляются наши интерфейсные ресурсы. Например, если сценарий основного потока и сценарий веб-воркера имеют общие зависимости, мы хотели бы загрузить зависимости один раз, а не объединять их дважды для каждого сценария. Некоторые инструменты поддерживают это «из коробки», некоторые требуют значительных усилий по настройке для изменения поведения по умолчанию, а для других это совершенно невозможно.
Этот опыт побудил нас изучить, что могут и чего не могут делать различные инструменты сборки. Мы надеялись создать контрольный список функций, чтобы в следующий раз, когда мы приступим к новому проекту, мы могли оценить и выбрать, какой инструмент лучше всего подходит для нашего проекта.
Наш подход
Как мы можем оценить и сравнить различные инструменты сборки в одном месте? Мы подошли к этому, написав тестовые примеры.
Наша команда обсудила и разработала критерии тестирования, которые, по нашему мнению, представляют собой лучшие практики веб-разработки. Мы специально сосредоточились на том, как обеспечить быстрый, отзывчивый и плавный пользовательский интерфейс, намеренно исключив тесты, связанные с опытом разработчиков, чтобы избежать измерения двух несравнимых результатов.
После создания списка тестов мы пошли дальше и написали сценарий сборки для каждого инструмента, чтобы проверить, может ли инструмент соответствовать критериям успеха теста. В качестве первоначального набора мы решили изучить Webpack v4, Rollup v2 и Parcel v2. Мы также протестировали Browserify + Gulp, поскольку большое количество проектов до сих пор используют эту настройку. Для успешного прохождения теста можно использовать только общедоступные функции инструмента или плагин для него. После написания первоначального набора тестов мы работали с авторами инструментов сборки, чтобы убедиться, что мы правильно используем их инструменты и честно их представляем.
Мы используем только ${tool_name}, должно ли меня это волновать?
Во многих командах есть люди, которые занимаются обслуживанием инфраструктуры сборки, а другим членам команды может никогда не понадобиться сделать выбор, когда дело доходит до инструментов сборки. Мы надеемся, что этот сайт по-прежнему будет полезен и вам, поскольку он поможет вам определить ожидания от инструментов, на которые вы полагаетесь. Для каждого теста мы включили объяснение важности теста, а также дополнительные ресурсы. А если вы хотите применить передовой опыт с выбранным вами инструментом, тестовая установка в нашем репозитории содержит необходимые для этого файлы конфигурации.
Могу ли я внести свой вклад в развитие сайта?
Если вы считаете, что следует протестировать определенную функцию, которая в настоящее время отсутствует, предложите ее в выпуске GitHub , чтобы начать обсуждение. Мы стремимся инкапсулировать реальные варианты использования, и любые дополнительные тесты, которые лучше оценят эти результаты, приветствуются.
Если вы хотите писать тесты для инструментов, которые мы не включили в первоначальный набор, мы это тоже приветствуем! Пожалуйста, посетите CONTRIBUTING.md для получения дополнительной информации.