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

Но как насчет соблюдения соглашений о кодировании, характерных для вашей компании, домена, проекта или команды?

Эта проблема проявляется следующими способами

  • Вы, как владелец кода или рецензент, несете ответственность за то, чтобы помнить обо всех соглашениях по кодированию в вашей команде и выявлять эти ошибки во время кодирования или PR-ревью.
  • Каждый раз, когда кто-то присоединяется к команде, вы должны приобщить его к этим соглашениям о кодировании.
  • Вы должны отслеживать и документировать любые новые соглашения о кодировании, с которыми согласилась ваша команда, и следить за тем, чтобы ваши участники читали и соблюдали документацию.
  • В конечном итоге вам придется исправлять проблемы, возникающие из-за этих ошибок, в продукте, хотя их можно было легко обнаружить ранее в цикле.

Чтобы решить эти проблемы, мы написали собственные правила и средства исправления ESLint для нашего проекта. Мы запускаем их во время компиляции кода и в конвейере CI/CD. Это выявляет проблемы во время кодирования, в PR и блокирует развертывание, если обнаружены какие-либо проблемы.

В этом блоге изложены наши выводы из написания пользовательских правил ESLint в нашей команде.

Как добавить пользовательские линтеры

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

Создание пользовательских линтеров

  1. Для начала откройте ASTExplorer и скопируйте-вставьте свой код, который нужно линтинговать, на левой верхней панели.
  2. Убедитесь, что настройки такие, как показано на скриншоте ниже.

3. На нижней левой панели вы можете начать писать свой собственный линтер. Вы можете воспользоваться документацией Работа ESlint с правилами.

4. И вот, немного зависнув над кодом, немного проб и ошибок, ваш линтер готов! Как видите, context.report() сообщит об ошибке в вашей среде IDE, терминале, CI/CD и т. д., где бы ни вызывался этап линтинга.

5. Вы можете скопировать и вставить код в нижней левой панели в свой репозиторий кода, выполнив шаги, описанные в этом блоге.

Примечание.

  • Вы можете расширить этот пример, используя context.getFilename() для конкретных файлов
  • Вы можете использовать фиксаторы, чтобы исправить эти нарушения на лету и т. д.
  • Будьте предельно ясны с отчетами о правилах, это сообщение, которое ваш разработчик увидит на своем терминале или в IDE, поэтому важно, чтобы его было легко понять, отладить и исправить.

Запуск линтера

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

npx eslint <fileName> –rule <customRule>
Example: npx eslint src/js/consts/fciInteractionConsts.ts — rule “{‘custom-rules/incorrect-fci-naming-convention’: 1}

Модульное тестирование линтера

Вы можете написать модульные тесты для своих пользовательских правил, используя RuleTester.

Тест можно запустить независимо с помощью такой команды, как следующая

jest test/custom-es-lint-rules.test.js --watch

Публикация пользовательского правила

Вы можете опубликовать свои собственные правила в артефакте npm вашей организации и использовать их в своем package.json, как и любое другое правило ESLint.

Если правило очень специфично для вашей кодовой базы и не оправдывает хлопот с публикацией в артефакте npm, вы всегда можете обновить версию локально в package.json своего пользовательского правила каждый раз, когда вносите изменения, а затем запускайте
yarn upgrade <your-custom-rule-package>в вашем репозитории.

Вуаля! У вас есть готовое пользовательское правило, и теперь вы можете позволить правилу отлавливать эти ошибки вместо того, чтобы следить за ними во время проверки кода!