Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.
Так звучит один из популярных вопросов на собеседовании для фронтенд-разработчиков. Я не знаю, что хочет услышать человек, задающий этот вопрос, но у меня есть ответ на его техническую составляющую и бэклог на несколько месяцев вперед.
Предисловие
В этой статье я буду опираться во многом на (осторожно, субъективное мнение, подтвержденное только внутренним чувством и количеством репозиториев на github) самый популярный сборщик статики — webpack. Если по какой-то причине в вашем проекте используется другой сборщик, то ничего страшного: аналоги инструментов, про которые пойдет речь, с большой вероятностью найдутся в поиске.
Но мой совет: если ваш проект не является npm-модулем, переведите сборку статики на webpack, так будет проще.
Метрики
Первое, что нужно сделать, это собрать метрики. Они помогут понять, что ситуация стала лучше, а не хуже. Можно начать с веса статики (JS, CSS, HTML, картинки и т.д.). Делается это на удивление просто: собираем продовую версию проекта и получаем вес файлов. Второй важной для нас метрикой можно считать web-performance. Её можно получить с помощью Lighthouse. Проводим замеры, сохраняем оценки. И мы готовы начать.
Неиспользуемые файлы
Нам необходимо облегчить себе жизнь за счёт удаления неиспользуемых файлов. Они мешают воспринимать проект, и порой могут сильно путать. К примеру, один раз я удалил файлов на полпроекта, они просто нигде не использовались. Для решения этой задачи можно использовать плагин под webpack — unused-files-webpack-plugin. Подключаем плагин, запускаем сборку, получаем в консоль список мусорных файлов. У плагина есть параметр failOnUnused, значение по умолчанию — false. Если вы хотите сделать проверку строгой, то меняем значение на true, и сборка будет падать, если кто-то оставит в проекте лишний файл.
Статический анализ кода
Мы удалили лишние файлы, а значит не попадем в ситуацию, когда после исправлений в конкретном файле оказывается, что он не нужен, и мы впустую потратили время. Первое, что рекомендую установить на вашу IDE, это плагин SonarLint. Он умеет анализировать не только JavaScript, но и множество языков (полный список тут). Устанавливаем, проверяем весь проект, видим ошибки, правим — профит.
Это, конечно же, не всё. Теперь нужно установить и настроить ESLint. Обратимся за помощью к довольно популярному конфигу от Airbnb: если у вас не React — eslint-config-airbnb-base, а если React — eslint-config-airbnb. Они различаются набором правил. Например, в пакете для React будут прописаны правила от ESLint-плагинов: eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y. Некоторые правила являются вкусовщиной, и если вам не по душе, например, висящие запятые, всегда можно поменять настройку правила.
Третьим шагом в нашем крестовом походе за стиль кода и качество кодовой базы будет подключение eslint-plugin-sonarjs. Плагин для ESLint никак не заменяет плагин для IDE, а лишь приятно дополняет.
В первых трёх шагах мы делали упор на JS, но во фронтовых проектах немало стилей, давайте перейдем к ним. Для всего, что не является Stylus'ом, мы будем использовать Stylelint, а для Stylus — Stylint.
Ожидаемо, что после внедрения SonarLint, ESlint и Stylelint или Stylint будет куча ошибок. Необязательно всё править за один раз, можно временно отключить правила и исправлять их по порядку, или перенастроить их до фикса на warning.
Зависимости
Львиную долю кода в проекте составляют зависимости. Во-первых, было бы неплохо знать инструменты, которыми мы пользуемся. Во-вторых, эти самые инструменты могут плохо повлиять на web-performance вашего приложения.
Идеальным инструментом для решения этой проблемы является плагин под webpack bundle analyzer. Он позволит посмотреть, что у приложения под капотом, найти самые тяжелые зависимости, а также зависимости, которые не должны были попасть в продовую сборку (например, prop-types, redux-devtools, hot-loader и т.д.).
Но у зависимостей есть еще одна проблема: они любят дублироваться. В большинстве своем из-за неправильно собранных npm-пакетов и разницы между мажорными версиями npm-пакетов.
Инструмент, который поможет нам найти дубли: duplicate-package-checker-webpack-plugin (да, это очередной плагин под webpack). По аналогии с unused-files-webpack-plugin, его можно настроить на строгую проверку и завершать сборку при найденном дубле. Для этого нужно задать параметру emitError значение true.
Что мы будем делать с найденными дублями?
- В любом случае, стоит освежить версии всех зависимостей.
- Если это не помогло, можно поискать аналог пакета, который создает проблемы. Делать это можно через сервис bundlephobia.
- Если аналога нет, попробуйте написать функциональность сами.
- Если писать самому не вариант, сделайте pull request.
Журналирование
После очистки кодовой базы от неиспользуемых файлов, правки стиля и разбирательства с зависимостями стоит прикрутить журналирование ошибок. Для этого прекрасно подходит Sentry. Она (он или оно) являлась де-факто стандартом везде, где я работал. Установить Sentry можно двумя способами:
- скриптом в HTML;
- как модуль через npm.
Я рекомендую устанавливать скриптом в HTML. Почему? Представим, что пользователь заходит на сайт, на котором используется модный и современный JavaScript. У пользователя старый браузер, и если тот не поймет синтаксис, пользователь получит неработающее приложение. Ведь если Sentry был установлен через пакет, он не сможет инициализироваться, чтобы отловить эту ошибку.
CI-пайплайн
Мы потратили немало времени, и чтобы проект не вернулся к изначальному состоянию, нам нужно автоматизировать все проверки, постаравшись исключить человеческий фактор хотя бы в этих частях.
Для этого напишем немного скриптов в package.json:
"scripts": {
"lint": "stylint src/ && eslint --ext .js,.jsx src/",
"prod": "BABEL_ENV=production webpack --env=prod --progress",
"build": "npm run lint && npm run prod"
}Что мы получим:
- Запускается линтинг JS (из package.json).
- Запускается линтинг CSS (из package.json).
- Запускается webpack (из package.json).
- Запускается unused-webpack-plugin (из webpack).
- Запускается duplicate-package-checker-webpack-plugin (из webpack).
Web-performance
Стоит потратить время на исправление ошибок, найденных Lighthouse (о нем я упоминал в начале статьи). В Chrome вы можете всё проверять вручную: переключитесь в режим разработчика, и попадёте во вкладку Lighthouse. Целесообразно проверять в режиме mobile: если в нём получится добиться хорошего результата, то в desktop всё будет отлично. Также можно использовать CLI.
Подведение итогов
В самом начале я упомянул, что бэклога хватит на несколько месяцев вперед. Это не значит, что на всех проектах всё займет одинаковое количество времени. Это, скорее, в среднем по больнице, учитывая, что большую часть рабочего времени мы решаем проблемы бизнеса.
Чего мы добились:
- Очистили проект от мусора.
- Стандартизировали стиль кода внутри проекта.
- Уменьшили вес кодовой базы.
- Улучшили UX.
- Настроили мониторинг.
- Собрали CI.
Как минимум, это всё можно использовать как аргумент на вашем performance review.
P.S.
Пример проекта с настройками можно посмотреть на github.
Автор: Денис
