Использование ESLint Right

Когда мы сотрудничаем над проектом, лучше (почти каждый раз) использовать какой-либо общий стиль кодирования, чтобы другие разработчики могли легко читать ваш код (и чтобы они не искали вас). Но как сделать так, чтобы все знали общий стиль кодирования? И как убедиться, что все следуют единому стилю кодирования?

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

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

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

Часть 1: Добавление ESLint в проект

Воспользуемся Экспресс-генератором, чтобы создать образец проекта.

Давайте запустим это, введя следующие команды:

cd myapp
npm install
DEBUG=myapp:* npm start

Итак, наш проект запущен и работает. Теперь нам нужно добавить ESLint.

Мы сделаем это с помощью следующей команды:

npm install --save-dev eslint

Мы не будем устанавливать ESLint глобально - это неправильно. И мы установим его только как зависимость для разработчиков.

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

 ./node_modules/.bin/eslint --init

Он задаст нам ряд вопросов. Я приложил все восемь вопросов в виде скриншотов. Я дал объяснение в подписи везде, где это необходимо.

Я лично слежу за гидом Airbnb. Это интересное чтение.

Это создаст .eslintrc.json в корне нашего проекта.

Часть 2: Использование ESLint

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

./node_modules/.bin/eslint . # . represent the current directory

Обратите внимание, что eslint является исполняемым файлом, и мы будем использовать версию, содержащуюся в нашем проекте. Все исполняемые файлы находятся в каталоге .bin каталога node_modules. Это дает нам возможность иметь разные версии ESLint для разных проектов без необходимости устанавливать их глобально. Фактически, все исполняемые файлы должны использоваться таким образом - например, nodemon, pm2 и т. Д.

Он дает следующий результат с множеством файловых ошибок / предупреждений и общим отчетом в конце.

Чтобы запустить ESLint в одном файле, мы используем:

./node_modules/.bin/eslint app.js

Мы также можем добавить еще один вариант исправления, чтобы ESLint исправлял все проблемы, которые он мог исправить сам.

 ./node_modules/.bin/eslint app.js --fix

Было исправлено 14 проблем, и теперь из неиспользуемых переменных осталась только одна. Чтобы выяснить, в чем проблема, мы ищем правило no-unused-vars, так как нужно время, чтобы привыкнуть к руководству по стилю Airbnb.

Позвольте мне запустить ESLint с командой fix для всего проекта.

./node_modules/.bin/eslint . --fix

Он исправил большинство ошибок для меня.

Часть 3: Добавление команды в package.json

Очень сложно набирать всю команду снова и снова. Следовательно, я предпочитаю создавать сокращенные команды в сценариях в package.json.

Теперь, если нам нужно запустить ESLint, мы можем просто использовать:

npm run lint

Это дает в итоге немного npm ERR!. Это потому, что ESLint выдает ненулевой код выхода (вы можете его проигнорировать).

Это очень легко запомнить и запустить любому разработчику.

Часть 4: Превалирующие правила

Что, если мы захотим выключить no-unsed-vars rule? Мы просто переопределим это правило в нашем .eslintrc.json файле.

И теперь мы увидим, что ESLint не выдает ошибок.

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

Часть 5. Заключение

Лучше использовать какой-нибудь линтер и направляющую, чем ничего не делать. Важно добавить это в ловушку перед фиксацией. Разработчики могут использовать git-хуки, поэтому важнее иметь это и в CI.

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