И работает с ESLint — подключаемый JavaScript Linter

Обзор правил

ESLint имеет более ста правил в своем арсенале. Мы не будем проходить через все из них, так как список действительно значительный. Мы просто проведем вас через некоторые из наиболее распространенных, чтобы дать вам представление о том, на что способен ESLint.

Вы можете включить любое из этих правил, перечислив его в свойстве rules в файле конфигурации. Каждому правилу может быть присвоено определенное значение: 0 (или off ), чтобы отключить правило, 1 или ( warn ), чтобы выдать предупреждение, и 2 (или error ), чтобы вызвать ошибку. Некоторые правила, такие как правила в нашем файле конфигурации, могут принимать массив с серьезностью в качестве первого элемента, за которым следуют дополнительные параметры. Обратитесь к документации, если вы не уверены, какие значения поддерживает конкретное правило.

Стилистические правила

Некоторые из правил довольно тривиальны и служат только для обеспечения определенного стиля кода:

• block-spacing — обеспечивает пробелы внутри блоков кода { ... } ;
• запятая — требует или запрещает висячие запятые в массивах или объектах;
• eol-last — вводит новую строку в конце каждого файла.

Как правило, не имеет значения, как вы настраиваете эти правила, если с ними согласна вся команда.

Лучшие практики

Существует ряд правил, которые охватывают руководящие принципы, которые, как считается, улучшают исходный код и приветствуются в сообществе разработчиков. Некоторые из интересных упоминаний:

• сложность — максимально допустимый порог цикломатической сложности в ваших источниках;
• default-case — всегда требовать блока по default в ваших операторах switch ;
• eqeqeq — требует использования операторов строгого сравнения: === и !== ;
• no-implicit-coercion — запрещает неявные методы преобразования типов, такие как !!false или +'2' ;
• no-magic-numbers — запрещает использование «магических чисел»: чисел, которые появляются в коде, но не имеют связанных идентификаторов;
• йода — требует или запрещает выписывать условия «йода»;
• no-shadow — запрещает « теневые » переменные: объявляет переменные с тем же именем, что и существующая переменная в родительской области.

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

Потенциальные ошибки

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

• no-cond-assign — запрещает присваивания в условных выражениях;
• no-dupe-args — запрещает дублирование аргументов в объявлениях функций;
• no-inner-декларации — запрещает объявление переменных функции ar во вложенных блоках;
• no-invalid-regexp — проверяет правильность ваших регулярных выражений;
• no-unreachable — проверяет, есть ли какой-либо недоступный код после операторов return , throw , continue или break .

ECMAScript 6

Существует еще один набор правил, состоящий из проверок, специфичных для стандарта ECMAScript 6. Если вы предпочитаете использовать новейшие функции, вы можете найти их интересными. Вот несколько примеров:

• constructor-super — требует вызовов super() в конструкторах;
• no-dupe-class-members — проверяет наличие дублированных членов класса;
• no-var — требует let или const вместо var .

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

Работает в разных средах

Когда мы изначально настраивали ESLint, мы ожидали, что наш код будет выполняться в браузере. Но предположим, что мы хотим использовать его и в среде Node.js. Например, мы хотели бы использовать функцию Node’s module.exports , добавив следующий фрагмент кода в наш пример:

 if (module && module.exports) { module.exports = doGood; } 

Повторный запуск линтера вызовет появление новых ошибок:

 10:5 error 'module' is not defined no-undef 10:15 error 'module' is not defined no-undef 11:5 error 'module' is not defined no-undef 

Это происходит потому, что линтер не ожидает появления в коде специфичных для узла переменных. Чтобы это исправить, мы можем проинструктировать его, чтобы он знал о среде Node:

 "env": { "browser": true, "es6": true, "node": true }, 

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

Комментарии к конфигурации

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

Представьте, что мы хотим отключить правило no-sparse-arrays в нашей функции. Мы можем сделать это, добавив следующий комментарий к этой строке:

 var toDoList = ["List",,"things","to do"]; // eslint-disable-line no-sparse-arrays 

Если мы хотим подавить все ошибки для нашей функции, мы можем eslint-disable/eslint-enable ее в блок eslint-disable/eslint-enable .

 /* eslint-disable */ function doGood() { var message = "doing good!"; var message = "or am i?"; console.log("doing something"); var toDoList = ["List",,"things","to do"]; // eslint-disable-line no-sparse-arrays } /* eslint-enable */ 

Или, чтобы отключить linting для всего файла, мы можем просто добавить один /* eslint-disable */ комментарий в начале файла.

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

Автоматическое исправление ошибок

ESLint обладает интересной способностью автоматически исправлять некоторые обнаруженные ошибки. Правила, которые могут автоматически исправить код, отмечены значком гаечного ключа в общем списке правил . На данный момент большинство этих правил носит чисто стилистический характер. Давайте попробуем запустить наш первоначальный пример через автокоррекцию. Для этого добавьте флаг --fix к команде, которую мы использовали для запуска ESLint:

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

Вот как будет выглядеть наш пример после исправления некоторых ошибок:

 function doGood() { var message = 'doing good!'; var message = 'or am i?'; console.log('doing something'); var toDoList = ['List',,'things','to do']; } 

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

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

Если вы чувствуете, что доступные встроенные и сторонние правила не покрывают все ваши потребности, вы можете написать свои собственные. ESLint предоставляет API, который позволяет создавать собственные правила. Этот предмет более технический, требует более глубокого знания JavaScript, Node, базового понимания синтаксических анализаторов и поэтому заслуживает отдельной статьи. Общая идея состоит в том, что каждое правило содержит две вещи: метаинформацию, такую ​​как имя и описание, и фактическую реализацию. Правило реализовано в виде объекта, содержащего набор обратных вызовов, которые вызываются, пока ESLint перебирает абстрактное синтаксическое дерево вашего кода JavaScript, предоставляя доступ к текущему узлу. По сути, это реализация шаблона «посетитель». Руководство разработчика ESLint содержит более подробную информацию, а также примеры того, как реализовать свои собственные правила.

В заключение

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

Вы используете ESLint? Если нет, вы бы хотели попробовать? Позвольте мне знать в комментариях ниже.