Lint staged husky не работает

Чистим код в Angular. Готовим ESLint, codelyzer, stylelint, husky, lint-staged и Prettier

Если вам не приходилось работать в команде, то, возможно, вы еще не используете эти вещи, а кто-то даже не знает про них. Работая один, вы сами себе хозяин.

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

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

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

Подготовка

Сразу отмечу, что примеры конфигурации довольно простые и не подходят для использования в продакшене, рассматриваются только ключевые моменты. Но ссылку на Angular-проект с готовой конфигурацией вы найдете в конце статьи.

Большинство инструментов, которые будут рассмотрены далее, можно применить не только к Angular, но в рамках этой статьи будем использовать Angular и начнем с того, что создадим новый проект:

TSLint (deprecated)

На текущий момент в проекте, который сгенерирован через Angular CLI, по умолчанию используется TSLint. Уже сейчас вам будет доступна команда npm run lint, которая запустит встроенную в CLI команду билдера ng lint, тем самым запустив проверку кода на соответствие codestyle.

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

TSLint: Запуск линтера в Angular-проекте

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

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

Однако на странице проекта в Гитхабе можно заметить, что TSLint помечен как deprecated, так что вместо него рекомендуют использовать ESLint (о нем расскажем далее).

Codelyzer

Помимо TSLint, который, исходя из названия, работает с TypeScript, в Angular-проекте хочется иметь правила, которые относятся конкретно к Angular.

И такое решение есть — codelyzer, который также по умолчанию устанавливается и настраивается при генерации проекта через Angular CLI. Правила codelyzer тоже применяются при запуске команды npm run lint. Это работает за счет файла конфигурации tslint.json, в котором интеграция TSLint и codelyzer осуществляется через свойство rulesDirectory.

ESLint

Так как TSLint был объявлен как deprecated, Angular-комьюнити начало движение в сторону ESLint. Если хочется узнать подробности, то на Хабре уже была статья, где подробно поясняется, почему стоит мигрировать.

На текущий момент (версия Angular 9.0.5) официальной поддержки ESLint в Angular еще нет, по этой причине CLI генерирует проект с TSLint и codelyzer. Стоит отметить, что codelyzer не совместим с ESLint и в этом случае рекомендуют начать использовать angular-eslint: тут есть builder и в планах — реализация schematic для автоматической миграции.
Также для миграции можно использовать решение от ESLint и написать свои правила с помощью eslint-plugin-typescript.

Если вы используете Nx, то в версии 9.1 появился плагин @nrwl/linter, поддерживающий ESLint.

Еще есть вариант использовать @tinkoff/linters, которые расширяют стандартный набор дополнительными наборами правил от Tinkoff. Последняя версия поддерживает ESLint, а предпоследняя — TSLint.

Однако, чтобы не отвлекаться, в рамках текущей статьи мы не будем рассматривать миграцию на ESLint, пока просто рекомендую помнить об этом.

Stylelint

А как же стили? И для стилей тоже есть решение. Встречайте — stylelint. Активно развивается, много чего поддерживает и в наличии множество готовых правил. Также есть песочница — там можно сформировать необходимый вам набор правил.

Устанавливаем сам stylelint, а также стандартный набор правил:

Определяем конфигурацию в файле .stylelintrc (другие способы можно найти здесь):

Добавляем скрипт в package.json, который можно запускать вручную для проверки стилей:

Далее запускаем и сразу ловим ошибку, так как по умолчанию в файле app.component.css стили отсутствуют, и это подпадает под правило no-empty-source, что показано на скриншоте ниже.

Stylelint: Первый запуск линтера стилей в Angular-проекте

Husky

Запускать вручную линтер каждый раз перед коммитом довольно утомительно, да и вообще можно запросто забыть это сделать. Чтобы делать это автоматически, существует пакет husky, который позволяет удобным образом использовать Git Hooks.
К примеру, если необходимо выполнить какую-нибудь команду до коммита, определяем соответствующее поведения для хука pre-commit.
Помимо вышеописанного хука есть возможность определить поведение для хука pre-push. Обычно не использую его, потому что запуск линтеров на pre-commit помогает делать более качественные коммиты.

Перейдем к практике. Как и договаривались, перед каждым коммитом будет автоматически запускаться команда npm run lint.
Для этого установим husky:

Определим конфигурацию в файле .huskyrc (можно хранить и в package.json, но попробуем альтернативный вариант):

После чего достаточно сделать коммит и посмотреть вывод:

Husky: Вывод в терминале при коммите

Как видно из скриншота, перед созданием коммита отработала команда ng lint, которая запустилась скриптом lint, определенным в package.json.
То есть получается следующая последовательность:

Husky → pre-commit hook → npm run lint → ng lint

Если команда вернет ошибку, коммит сделать не получится, придется исправлять найденные недочеты.

Lint-staged

В проект подключен husky, разработка ведется очень активно, и линтер запускается на каждый коммит, защищая код в соответствии с codestyle.

Однако, со временем, разработчики начинают замечать, что линтер что-то долго работает и кое-кто даже стал предлагать отключить линтер (ведь все и так уже знают codestyle, зачем ждать!). Отключать линтер, конечно же, не вариант, поэтому давайте определим, в чем проблема.

А проблема в том, что линтер запускается вообще для всех файлов проекта, а не только для тех, которые были изменены в процессе разработки. Так что при запуске линтера логичным будет учитывать только измененные файлы. Кроме этого, нас интересуют только те файлы, которые планируются добавить в коммит, а конкретно — файлы в статусе staged (подробнее про статусы файлов в git можно почитать здесь).

Переходим к практике.
Установим lint-staged:

Определим конфигурацию в файле .lintstagedrc (другие варианты описания конфигурации можно найти здесь). Далее настроим, что следует запускать скрипт линтера на файлы с расширением js и ts, а также еще один — на файлы с расширением css:

Не забудем про husky, ведь именно благодаря ему запускается хук на pre-commit. Теперь в последовательность добавляется lint-staged, который будет работать в качестве фильтра файлов, не давая запускать линтер на все файлы подряд:

Теперь последовательность выглядит так:

Husky → pre-commit hook → lint-staged
→ tslint
→ stylelint

Prettier

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

• Prettier может автоматически исправить любой код (auto fix). Да, тот же TSLint тоже умеет автоматически исправлять код, но не весь. Обратите внимание на пометку Has Fixer в его правилах. То же самое касается и stylelint: он умеет исправлять стили, где это возможно, через использование экспериментального флага —fix. В prettier есть соглашения по умолчанию, так что ваш код будет приведен к единому стилю.
• Выполняет более “умное” автоисправление. Подробнее можно прочитать здесь.
• Умеет интегрироваться с некоторыми линтерами, в том числе с ESLint, TSLint, stylelint.
• Умеет интегрироваться с различными IDE.
• Поддерживает множество форматов.
• Расширяется за счет плагинов.

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

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

Перейдем к практике.
Устанавливаем Prettier и необходимые наборы правил для интеграции с TSLint и stylelint:

Добавляем интеграцию для TSLint через файл tslint.json:

Здесь важно уточнить: поскольку ESLint/TSLint и Prettier частично решают схожие задачи, они могут конфликтовать между собой.
Эти конфиги нужны для устранения конфликта, а именно — для делегирования форматирования полностью в руки Prettier.
Далее добавляем интеграцию для stylelint в файл .stylelintrc:

Описываем конфигурацию для Prettier в .prettierrc:

Чтобы проверить интеграцию, выполните следующие команды:

Также добавим команду для запуска prettier в package.json:

Не забудем обновить конфиг lint-staged, чтобы Prettier запускался автоматически перед коммитом:

Так как Prettier только что добавлен, необходимо запустить его:

Итоги

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

Если вы работаете в команде, ведете разработку на Angular, но еще не настроили линтеры — самое время сделать это и эта статья точно для вас. Если же вы не используете Angular, то с небольшими доработками сможете адаптировать все вышеописанное под свой проект.

Код решения, рассмотренного в рамках этой статьи, можно найти в этом репозитории.

Также обратите внимание на @tinkoff/linters, который представляет собой готовое решение с нашими дополнительными наборами правил.
И для быстрого старта рекомендую посмотреть на вот этот репозиторий, где вы найдете готовую конфигурацию, в том числе и по линтерам.

Источник

Prettier, ESLint, Husky, Lint-Staged и EditorConfig: инструменты для написания аккуратного кода

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

Может быть вы — тимлид, под началом которого трудится команда разработчиков разного уровня? В вашей команде есть новые люди? Беспокоит ли вас то, что код, который они напишут, не будет соответствовать вашим стандартам? Проходят ли ваши дни в проверках чужого кода, когда эти проверки, в основном, касаются соблюдения стандартов, а не программной логики?

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

А именно, здесь пойдёт речь о таких средствах как Prettier, ESLint, Husky, Lint-Staged, EditorConfig, об автоматизации форматирования и линтинга кода. Этот материал ориентирован, в основном, на React-разработку, но рассмотренные здесь принципы можно применить в любом веб-проекте. Вот репозиторий, где, кроме прочего, собрано то, о чём тут пойдёт речь.

Prettier

Prettier — это средство для форматирования кода, которое нацелено на использование жёстко заданных правил по оформлению программ. Оно форматирует код автоматически. Вот как это выглядит.

Prettier форматирует код, следуя правилам

▍Сильные стороны Prettier

Вот какие возможности и особенности Prettier позволяют говорить о полезности этого инструмента:

• Приведение в порядок существующей кодовой базы. Подобное, с помощью Prettier, можно выполнить буквально одной командой. Ручная обработка больших объёмов кода займёт гораздо больше времени. Представьте себе, например, затраты труда, необходимые для того, чтобы вручную отформатировать 20000 строк кода.
• Prettier легко внедрить. Prettier использует «усреднённый», наименее спорный подход к стилю при форматировании кода. Так как проект это опенсорсный, многие внесли в него вклад, улучшая его и сглаживая острые углы.
• Prettier позволяет сосредоточиться на написании кода, а не на его форматировании. Многие просто не осознают того, как много времени и сил тратится на форматирование кода. Использование Prettier позволяет не думать о форматировании, а заниматься вместо этого программированием. В моём случае, например, эффективность работы, благодаря Prettier, выросла на 10%.
• Prettier помогает начинающим. Если вы — начинающий программист, работающий в одной команде с серьёзными профессионалами, и вы хотите достойно смотреться на их фоне, в этом вам поможет Prettier.

▍Настройка Prettier

Вот как использовать Prettier в новом проекте. Создайте папку app , и, перейдя в неё, выполните следующую команду в командной строке:

Благодаря этой команде npm инициализирует новый проект в папке app , создав в ней файл package.json .

Я, в этом материале, буду использовать yarn , но тут можно использовать и npm . Prettier можно подключить и к существующему проекту.

Установим пакет prettier в качестве зависимости разработки нашего проекта:

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

О том, что означает строка «prettier»: «prettier — write src/**/*.js» , мы поговорим чуть позже. А пока создадим в папке app папку src . В этой папке создадим файл index.js , хотя назвать его можно как угодно.

В этот файл внесём следующий код (именно в таком вот неприглядном виде):

Итак, на данный момент у нас имеется файл src/app/index.js , в котором находится довольно-таки плохо оформленный код.

Как это исправить? Существует три подхода к работе с плохо отформатированным кодом:

1. Вручную отформатировать этот код.
2. Использовать автоматизированный инструмент.
3. Оставить всё как есть и работать дальше (прошу вас не выбирать этот подход).

Я собираюсь выбрать второй вариант. Сейчас в нашем проекте есть соответствующая зависимость, и, кроме того, в разделе scripts файла package.json есть запись о Prettier. Понятно, что мы воспользуемся для форматирования кода именно этим инструментом. Для того чтобы это сделать, создадим файл prettier.config.js в папке app и добавим туда правила для Prettier:

Разберём эти правила:

• printWidth: 100 — длина строки не должна превышать 100 символов.
• singleQuote: true — все двойные кавычки будут преобразованы в одинарные. Подробности об этом можно почитать в руководстве по стилю от Airbnb. Мне очень нравится это руководство, я использую его для повышения качества моего кода.
• trailingComma: ‘all’ — обеспечивает наличие запятой после последнего свойства объекта. Вот хорошая статья на эту тему.
• bracketSpacing: true — отвечает за вставку пробелов между телом объекта и фигурными скобками в объектных литералах. Если это свойство установлено в true , то объекты, объявленные с использованием объектных литералов, будут выглядеть так: < foo: bar >. Если установить его в false , то такие конструкции будут выглядеть так: .
• jsxBracketSameLine: false — благодаря этому правилу символ > в многострочных JSX-элементах будет помещён в последней строке. Вот как выглядит код, если это правило установлено в true :

Вот что произойдёт, если оно установлено в значение false :

• tabWidth: 2 — задаёт количество пробелов на один уровень выравнивания.
• semi: true — если это правило установлено в true , то в конце выражений добавляется точка с запятой.

Здесь можно найти сведения по всем правилам Prettier.

Теперь, когда правила настроены, поговорим об этом скрипте:

Благодаря этой конструкции Prettier запускается и находит все .js -файлы в папке src . Флаг —write указывает ему на то, чтобы он сохранял отформатированные файлы по мере их обработки и исправления найденных в них ошибок форматирования.

Запустим скрипт из командной строки:

Вот что стало после этого с показанным выше плохо отформатированным кодом.

Результат форматирования кода с помощью Prettier

На этом будем считать, что с Prettier мы разобрались. Поговорим о линтерах.

ESLint

Линтинг — это вид статического анализа кода, который часто используют для нахождения проблемных паттернов проектирования или кода, который не следует определённым руководствам по стилю.

Существуют линтеры, предназначенные для большинства языков программирования, иногда компиляторы включают линтинг в процесс компиляции кода. Это определение линтинга взято со страницы информации об опенсорсном линтере для JavaScript ESLint, о котором мы и поговорим.

▍Зачем нужен линтер для JavaScript?

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

Линтеры, наподобие ESLint, позволяют разработчикам находить проблемы в коде, не запуская его.

▍Почему ESLint — это особенный инструмент?

В заголовок этого раздела вынесен хороший вопрос. Дело тут в том, что ESLint поддерживает плагины. Так, правила проверки кода не должны представлять собой монолитный пакет. Всё, что нужно, можно подключать по мере необходимости. Каждое добавляемое в систему правило линтинга автономно, оно может быть, независимо от других, включено или выключено. Каждому правилу можно назначить уровень оповещения в соответствии с желанием разработчика — это может быть предупреждение (warning) или ошибка (error).

При использовании ESLint вы работаете с полностью настраиваемой системой, способной отразить ваше понимание того, как должен выглядеть правильный код, и зафиксировать то, какого свода правил вы придерживаетесь.

Среди существующих руководств по стилю JavaScript можно отметить следующие, весьма популярные:

• Google JavaScript Style Guide
• Airbnb JavaScript Style Guide

Я, как уже говорилось, использую руководство по стилям от Airbnb. Мне посоветовал этот документ мой руководитель в компании, в которой началась моя профессиональная карьера, и я считаю это руководство по стилям самым ценным своим активом.

Это руководство активно поддерживается — взгляните на его репозиторий на GitHub. Здесь я буду использовать набор правил, основанный именно на нём.

Сейчас давайте поработаем над файлом package.json , добавим в него некоторые зависимости:

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

Поэтому обсудим роль представленных здесь пакетов:

• babel-eslint — позволяет использовать линтинг в применении ко всему тому, что даёт Babel. Этот плагин вам не нужен в том случае, если вы не используете Flow или экспериментальные возможности, которые пока не поддерживает ESLint.
• eslint — это основной инструмент, который используется для линтинга кода.
• eslint-config-airbnb — предоставляет правила Airbnb в виде конфигурации, которую можно модифицировать.
• eslint-plugin-babel — это плагин для ESLint, дополняющий плагин babel-eslint . В нём переделаны правила, которые, при применении babel-eslint , вызывают проблемы при обработке экспериментальных возможностей.
• eslint-plugin-import — этот пакет поддерживает линтинг свежих синтаксических конструкций import/export и позволяет предотвращать проблемы, связанные с неправильным написанием путей к файлам и имён импортируемых модулей.
• eslint-plugin-jsx-a11y — предоставляет правила, касающиеся доступности JSX-элементов для людей с ограниченными возможностями. Доступность веба — это очень важно.
• eslint-plugin-prettier — помогает совместной работе ESLint и Prettier. Выглядит это следующим образом: когда Prettier форматирует код, он делает это с учётом правил ESLint.
• eslint-plugin-react — содержит ESLint-правила, рассчитанные на React.

В этом материале мы не говорим о тестировании кода, но в представленном выше package.json есть зависимости, предназначенные для модульного тестирования с использованием Jest/Enzyme. Вот, если вы решите воспользоваться этими средствами для тестирования, описание соответствующих пакетов.

• eslint-config-jest-enzyme — данный пакет предназначен для тех случаев, когда пользуются jest-environment-enzyme , что приводит к тому, что переменные React и Enzyme оказываются глобальными. Благодаря ему ESLint не будет выдавать предупреждения о таких переменных.
• eslint-plugin-jest — ESlint-плагин для Jest.

В файле есть ещё пара пакетов, которые мы обсудим позже, обсуждая вопросы автоматизации. Это husky и lint-staged .

Теперь, когда мы, в общих чертах, обсудили наши инструменты, продолжим работу.
Создадим файл .eslintrc.js в папке app :

Теперь добавим в папку app файл .eslintignore :

Поговорим теперь о том, как устроен файл .eslintrc.js , и о том, какой смысл несут представленные в нём конструкции.

Этот файл имеет следующую структуру:

Рассмотрим блоки этого файла, представленные объектами с соответствующими именами:

• env — позволяет задавать список сред, код для которых планируется проверять. В нашем случае тут имеются свойства es6 , browser и node , установленные в true . Параметр es6 включает возможности ES6 за исключением модулей (эта возможность автоматически устанавливает, в блоке parserOptions , параметр ecmaVersion в значение 6 ). Параметр browser подключает глобальные переменные браузера, такие, как Windows . Параметр node добавляет глобальные переменные среды Node.js и области видимости, например — global . Подробности о средах можно почитать здесь.
• extends — представляет собой массив строк с конфигурациями, при этом каждая дополнительная конфигурация расширяет предыдущую. Здесь используются правила линтинга airbnb , которые расширены до jest и затем расширены до jest-enzyme .
• plugins — тут представлены правила линтинга, которые мы хотим использовать. У нас применяются правила babel , import , jsx-a11y , react , prettier , о которых мы уже говорили.
• parser — по умолчанию ESLint использует синтаксический анализатор Espree, но, так как мы работаем с Babel, нам надо пользоваться Babel-ESLint.
• parserOptions — так как мы изменили стандартный синтаксический анализатор на babel-eslint , нам необходимо задать и свойства в этом блоке. Свойство ecmaVersion , установленное в значение 6 , указывает ESLint на то, что проверяться будет ES6-код. Так как код мы пишем в EcmaScript -модулях, свойство sourceType установлено в значение module . И, наконец, так как мы используем React, что означает применение JSX, то в свойство ecmaFeatures записывается объект с ключом jsx , установленным в true .
• rules — эта часть файла .eslintrc.js нравится мне больше всего, так как она позволяет настраивать правила ESLint. Все правила, которые мы расширили или добавили с помощью плагинов, можно менять или переопределять, и делается это именно в блоке rules . В тексте файла имеются комментарии к правилам.

Теперь поговорим о файле .eslintignore . Этот файл принимает список путей, представляющий папки, содержимое которых не должно обрабатываться с помощью ESLint.

Здесь заданы три папки:

• /.git — мне не нужно, чтобы ESLint проверял файлы, относящиеся к Git.
• /.vscode — в проекте имеется эта папка из-за того, что я использую VS Code. Тут редактор хранит конфигурационные сведения, которые можно задавать для каждого проекта. Эти данные тоже не должны обрабатываться линтером.
• node-modules — файлы зависимостей также не нужно проверять линтером.

Сейчас рассмотрим пару новых скриптов, появившихся в package.json . Вот они:

Если выполнить первый из них, с помощью команды yarn lint или npm run lint , это приведёт к тому, что линтер просмотрит все файлы в директории src и выведет подробный отчёт по файлам, в которых он нашёл ошибки. Пользуясь этим отчётом можно эти ошибки исправить.

Запуск скрипта lint

Если выполнить второй скрипт ( yarn lint:write ), то ESLint выполнит такую же проверку, которая была выполнена раньше. Единственное различие заключается в том, что в таком режиме система попытается исправить обнаруженные ошибки, постарается привести код в как можно более пристойный вид.

Расширение ESLint для VS Code

У нас уже есть настроенные Prettier и ESLint, но, чтобы пользоваться возможностями этих инструментов, нам приходится запускать скрипты. Это не очень-то удобно, поэтому попробуем это исправить. А именно, мы хотим добиться того, чтобы форматирование и линтинг кода выполнялись бы по команде сохранения файла в редакторе. Кроме того, выполнять линтинг и форматирование кода мы хотим перед выполнением коммитов.

Мы, в качестве примера, используем редактор VS Code. Нам понадобится расширение ESLint для VS Code. Для того чтобы установить его, можно открыть панель расширений VS Code ( ctrl+shift+x ). Тут, в поле поиска, надо ввести eslint . Появится список расширений. Нас интересует то, в сведениях о разработчике которого указан Dirk Baeumer. После установки этого расширения перезагрузим редактор.

Теперь, в корневой папке проекта ( app ), создайте папку .vscode (обратите внимание на точку в начале имени — это важно). В этой папке создайте файл settings.json следующего содержания:

Рассмотрим его содержимое.

• Свойство editor.formatOnSave , установленное в значение false , указывает на то, что нам не нужно, чтобы стандартная конфигурация применялась бы к форматированию файла, так как это может вызвать конфликт с ESLint и Prettier.
• Свойство eslint.autoFixOnSave установлено в true , так как нужно, чтобы установленный плагин срабатывал бы каждый раз, когда сохраняют файл. Так как ESLint и Prettier в проекте работают совместно, сохранение файла приводит и к форматированию, и к линтингу кода.

Важно отметить, что теперь, когда запускается скрипт lint:write , он выполнит и линтинг и форматирование кода.

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

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

Husky

Пакет Husky позволяет задействовать хуки Git. Это означает, что у вас появляется возможность выполнять некие действия перед выполнением коммита или перед отправкой кода репозиторий.

Для того чтобы воспользоваться возможностями Husky, сначала установим этот пакет:

После этого добавим в package.json следующее:

Это приведёт к тому, что перед выполнением команды commit или push будет вызван некий скрипт, который, например, выполняет тестирование кода или его форматирование.

Подробности о Husky можно почитать здесь.

Lint-staged

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

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

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

Установим пакет Lint-staged:

Затем, в файл package.json , добавим следующее:

Благодаря этой конструкции сначала будет выполняться команда lint:write , производящая проверку содержимого файла и исправление ошибок, после чего файлы будут добавляться в индекс командой git add . Сейчас эта команда нацелена на .js и .jsx -файлы, но то же самое можно делать и с файлами других типов.

Совместное использование Husky и Lint-staged

Рассмотрим схему действий, которая позволяет организовать следующий рабочий процесс. Каждый раз, когда вы коммитите файлы с кодом, перед выполнением этой операции, система запускает скрипт lint-staged , который, в свою очередь, запускает скрипт lint:write , выполняющий линтинг и форматирование кода. После этого файлы добавляются в индекс, а затем коммитятся. Мне кажется, что это очень удобно. На самом деле, в ранее представленном коде файла package.json это уже реализовано, просто раньше мы об этом не говорили.

Приведём снова, для удобства, содержимое нашего package.json :

Теперь, зная о Husky и Lint-staged, вы можете оценить их влияние на работу с Git. А именно, предположим, что были выполнены следующие команды:

Понятно, что перед коммитом код будет проверен на соответствие правилам, заданным в .eslintrc.js , и, при необходимости, исправлен. Благодаря этому ошибки никогда не проберутся в репозиторий рабочего проекта.

Теперь вы знаете о том, как интегрировать Prettier, ESLint, Husky и Lint-staged в свой проект.

Напомню, что выше мы говорили о том, что далеко не все члены вашей команды пользуются любимым мной VS Code. Для того чтобы всем им было удобно работать, нам понадобится разобраться с файлом .editorconfig .

Файл .editorconfig

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

На сайте проекта можно найти список редакторов, которые поддерживают этот файл. В него, в частности, входят WebStorm, AppCode, Atom, Eclipse, Emacs, BBEdit и другие.

Создадим в папке app нашего проекта файл .editorconfig и добавим в него следующий код:

Поясним настройки, использованные в этом файле:

• trim_trailing_whitespace = false — удаление пробелов в конце строк в .md -файлах не производится. Аналогичный параметр для .js -файлов установлен в false .
• indent_style = space — отступы оформляются пробелами а не знаками табуляции.
• indent_size = 2 — размер отступа равен двум пробелам.
• end_of_line = lf — перевод строки оформляется символом lf . Это позволит всем, независимо от применяемых ими операционных систем, пользоваться одним и тем же символом перевода строки. Подробности об этом смотрите здесь.
• insert_final_newline = true — в конце файла должна быть пустая строка.
• max_line_length = 100 — максимальная длина строки установлена в 100 символов.

Итоги

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

Уважаемые читатели! Какими инструментами вы пользуетесь для проверки и форматирования кода? Как автоматизируете эти процессы?

Источник