Автоматическое применение ESLint

За последние пару месяцев в рамках перехода от обеспечения качества к качественной помощи наши разработчики сосредоточили значительную часть своего времени и усилий на настройке нескольких различных типов автоматизированных тестов. Как часть нашей относительно новой кодовой базы для сайта Autotrader, в настоящее время мы работаем над сквозным тестированием с использованием Cypress, модульным тестированием с помощью Jest и визуальным тестированием с использованием Percy.

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

Что такое линтинг?

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

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

Зачем линтировать ваш JavaScript?

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

Запуск ESLint до любой проверки кода также означает, что разработчикам больше не нужно тратить время на рассмотрение структуры кода как части процесса проверки кода.

ESLint

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

Правила ESLint

Сайт Autotrader - это одностраничное приложение, созданное с использованием Vue.js, и поэтому было важно использовать ESLint для обеспечения соблюдения лучших практик не только для JavaScript, но и для Vue.js. Расширяемый характер ESLint позволяет включать сторонние правила в массив extends, предоставляемый как пакеты npm.

extends: [
  'eslint:recommended',
  'plugin:vue/recommended'
]

Для поддержки Vue.js мы добавили правила 'vue / Recommended' через пакет eslint-plugin-vue, который обеспечивает линтинг на основе официального Руководства по стилю Vue.js и обслуживает Один файл. Компоненты".

Основная причина создания ESLint заключалась в том, чтобы позволить разработчикам создавать свои собственные правила линтинга. Пользовательские правила линтинга можно определить в объекте rules файла .eslintrc. *. Например, в настоящее время у нас отключено правило 'no-console', как показано ниже.

rules: {
  'no-console': 'off',
  'no-trailing-spaces': 1,
  'vue/script-indent': [ 'error', 2, { 'baseIndent': 0 } ],
  'comma-dangle': ['error', 'always-multiline'],
  'array-bracket-spacing': [ 'error', 'always' ],
  'object-curly-spacing': [ "error", 'always' ],
  'keyword-spacing': [ 'error', { 'before': true, 'after': true } ],
}

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

В проекте может существовать несколько файлов .eslintrc. *. ESLint выбирает файл, который расположен ближе всего к текущему файлу, обрабатываемому для линтинга.

Если вам нужно применить определенные правила к определенной части вашего приложения, вы просто включаете дополнительный файл .eslintrc. * в соответствующую подпапку. Это приводит к тому, что эти новые правила отменяют существующие правила для файлов в этой подпапке.

Для наших тестов Cypress я включил новый файл .eslintrc. * в нашу подпапку Cypress, который позволяет нам использовать объект cy и перехватчик before без ESLint предупреждает нас, что они не определены.

ESLint при сохранении

Я хотел убедиться, что все разработчики оптимально настроили ESLint в рамках выбранной ими среды разработки. Ошибки должны не только выделяться, но и автоматически исправляться путем выполнения команды eslint --fix при каждом сохранении файла.

В настоящее время я использую VSCode и чтобы ESLint при сохранении работал, я установил расширение ESLint VSCode и добавил следующее в файл settings.json.

"eslint.validate": [
  {
    "language": "vue",
    "autoFix": true
  },
  {
    "language": "javascript",
    "autoFix": true
  }
],
"eslint.autoFixOnSave": true,
"editor.formatOnSave": false,
"vetur.validation.template": false,

Последние 2 строки выше необходимы, чтобы избежать конфликта валидации со стороны вашего редактора или плагина Vetur, если он у вас установлен.

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

См. Раздел Интеграции редактора этого руководства пользователя, чтобы узнать, как настроить IDE для автоматического исправления при сохранении.

ESLint при предварительной фиксации

Хуки Git позволяют автоматизировать задачи во время потока git. Обычной точкой для запуска автоматизированной задачи является ловушка перед фиксацией. Обратной стороной хуков git является то, что они расположены в каталоге .git, что означает, что они не фиксируются и поэтому не используются разработчиками. Пакет Husky позаботится об этом, автоматически создав сценарии в .git/hooks , когда разработчик запускает npm install.

Как только мне удалось успешно запустить ESLint при предварительной фиксации, я вскоре понял, что по умолчанию ESLint запускает процесс lint для всего проекта. Это далеко не идеально, так как он медленный и приводит к тысячам предупреждений и ошибок, которые необходимо исправить, прежде чем любое изменение кода может быть успешно зафиксировано. Нам нужно связывать только те файлы, которые были изменены, что позволяет команде медленно переносить все, чтобы принять согласованный стиль кода.

Решением оказался пакет lint-staged, который позволяет линтировать только staged файлы. Настройка Husky и lint-staged относительно проста. Сначала установите два пакета.

npm install husky lint-staged --save-dev
npm install lint-staged --save-dev

Следующим шагом является настройка ловушки предварительной фиксации с помощью Husky в вашем package.json следующим образом:

"husky": {
  "hooks": {
    "pre-commit": "npm run lint-staged"
  }
}

Я также добавил следующее в файл package.json для запуска ESLint на любых поэтапных файлах Vue. Чтобы остановить фиксацию, если появятся какие-либо предупреждения, я включил --max-warnings 0, как показано ниже.

"lint-staged": {
  "*.vue": [
    "eslint --max-warnings 0"
  ]
}

Итак, теперь каждый раз, когда разработчик фиксирует код, Husky запускает ловушку предварительной фиксации, которая запускает lint-staged для запуска eslint --fix для любых промежуточных файлов, за которыми следует git add. Это работает должным образом, независимо от того, используете ли вы командную строку или Sourcetree для фиксации кода.

Если поэтапный код вызывает ошибку или предупреждение ESLint, фиксация завершится ошибкой, и отобразится сообщение с описанием проблемы (-ов) и ее местоположением, что позволит разработчику быстро найти и исправить проблему (-ы). Если IDE разработчика правильно настроена с исправлением ESLint при сохранении, то фиксация кода не должна быть проблемой, потому что любые проблемы с линтингом уже должны были быть выделены и исправлены.

Чистый последовательный код

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