Когда мы сотрудничаем над проектом, лучше (почти каждый раз) использовать какой-либо общий стиль кодирования, чтобы другие разработчики могли легко читать ваш код (и чтобы они не искали вас). Но как сделать так, чтобы все знали общий стиль кодирования? И как убедиться, что все следуют единому стилю кодирования?
Ответ на первый вопрос заключается в использовании какого-то линтера, программы, которая подчеркивает отклонение от общепринятого руководства по стилю кодирования. Для 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 с использованием хаски.