У современных разработчиков Javascript есть множество вариантов, когда дело доходит до соблюдения соглашений о стилях и кодировании Javascript. Существует множество правил и плагинов ESLint для обеспечения соблюдения желаемого соглашения о кодировании.
Но как насчет соблюдения соглашений о кодировании, характерных для вашей компании, домена, проекта или команды?
Эта проблема проявляется следующими способами
- Вы, как владелец кода или рецензент, несете ответственность за то, чтобы помнить обо всех соглашениях по кодированию в вашей команде и выявлять эти ошибки во время кодирования или PR-ревью.
- Каждый раз, когда кто-то присоединяется к команде, вы должны приобщить его к этим соглашениям о кодировании.
- Вы должны отслеживать и документировать любые новые соглашения о кодировании, с которыми согласилась ваша команда, и следить за тем, чтобы ваши участники читали и соблюдали документацию.
- В конечном итоге вам придется исправлять проблемы, возникающие из-за этих ошибок, в продукте, хотя их можно было легко обнаружить ранее в цикле.
Чтобы решить эти проблемы, мы написали собственные правила и средства исправления ESLint для нашего проекта. Мы запускаем их во время компиляции кода и в конвейере CI/CD. Это выявляет проблемы во время кодирования, в PR и блокирует развертывание, если обнаружены какие-либо проблемы.
В этом блоге изложены наши выводы из написания пользовательских правил ESLint в нашей команде.
Как добавить пользовательские линтеры
Для этого блога давайте возьмем пример, в котором мы хотим, чтобы наши константы трассировки соответствовали определенному соглашению, как показано ниже.
Создание пользовательских линтеров
- Для начала откройте ASTExplorer и скопируйте-вставьте свой код, который нужно линтинговать, на левой верхней панели.
- Убедитесь, что настройки такие, как показано на скриншоте ниже.
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>
в вашем репозитории.
Вуаля! У вас есть готовое пользовательское правило, и теперь вы можете позволить правилу отлавливать эти ошибки вместо того, чтобы следить за ними во время проверки кода!