Навіщо (і як) використати eslint у вашому проекті

На npmjs.org є сотні тисяч пакетів, але це не означає, що вони мають однакову якість. Важливо перевірити, наскільки добре керуються ваші прямі залежності. Жоден з відсутніх методів керування не повинен виключати пакет з вашого розгляду, якщо функції правильні, але коли у вас є вибір пакетів, виберіть ті, які добре керуються – або будьте готові підтримувати пакет самостійно!

Я збираюся написати про кілька методів, які я використовую для оцінки проектів:

• наявність репозиторію github.com,
• корисний README,
• використання семер,
• набір тестів, що працює з git clone; npm i; npm test ,
• і т.п.

Сьогоднішня тема – лінтинг.

Навіщо лінтувати JavaScript?

Добре працюють проекти мають чіткі погоджені угоди про кодування з автоматичним виконанням. Коли я переглядаю проект, і його код виглядає як будинок, збудований дитиною, використовуючи лише сокиру та зображення будинку, це не вселяє впевненості в тому, що код працює.

Відсутність правил кодування також є перешкодою для залучення вкладів, а залежність від проекту, який не вітає (якісні!) вклади, сама по собі є ризиком.

Крім стилю перевірки, лінтери також є відмінним інструментом для пошуку певних класів помилок, наприклад, пов'язаних із областю видимості змінних. Надання неоголошеним змінним (вони просочуються в глобальну область видимості, забруднюючи її і, можливо, викликаючи дуже важке виявлення помилок) і використання невизначених змінних є прикладами помилок, які можна виявити під час lint.

Як настроїти eslint?

eslint - це основний інструмент для лінтингу пакетів Node.js, який можна налаштувати для застосування кількох стилів кодування. Можна визначити власні визначення стилю, але тут я покажу, як використовувати стиль StrongLoop. Є й інші, але стиль StrongLoop нічим не примітний (добре стиль кодування не повинен привертати уваги) і схожий на той, який використовується в багатьох проектах Node.js з відкритим вихідним кодом.

Встановіть та збережіть залежності пакетів:

npm install --save-dev eslint eslint-config-strongloop

Налаштуйте eslint для використання конфігурації strongloop , запустивши:

Переконайтеся, що у вас є .gitignore файл (щоб похідні файли не лінтувались, а лише вихідні файли). Якщо у вас його немає, мінімальний можна створити за допомогою:

echo node_modules/ >> .gitignore

Зверніть увагу, що також можна використовувати файл .eslintignore , специфічний для eslint, який має той же синтаксис, що .gitignore , і, ймовірно, такий же вміст. Щоб уникнути цього тягаря обслуговування, у більшості проектів використовується тільки .gitignore.

При такому налаштуванні налаштуйте eslint на автоматичний запуск перед тестами, змінивши package.json на script pretest. Це має виглядати приблизно так:

Точний вміст вашого package.json залежить від вашого проекту, це pretest скрипт, який ви повинні додати, щоб eslint запускався перед вашими модульними тестами (коли ви використовуєте npm для запуску тестового скрипта, він також буде запускати скрипти pretest і posttest якщо вони є). Я вважаю за краще це, тому що eslint зазвичай виконується набагато швидше, ніж мої тести, і помилки lint легко виправити, але деякі люди воліють запускати весь набір тестів перед лінтером, і в цьому випадку використовуйте posttest.

Зафіксуйте підтримку автоматизації eslint:

git add package.json .gitignore .eslintrc.json git commit -m 'Add eslint automation'

Як тільки це буде завершено, запустіть лінтер:

Не засмучуйтесь, якщо ваша консоль захлисне море помилок!

Як нам очистити існуючий код від ворсу?

Одна з причин, через яку деякі уникають використання eslint, полягає в тому, що очищення коду, в якому ніколи не було слідів, може нагадувати очищення Авгієвої стайні. Я рекомендую зробити так само, як Геракл: отримати допомогу від інструментів.

eslint може автоматично виправляти багато синтаксичних проблем, це має бути перший інструмент, який ви використовуєте для очищення вихідного коду:

./node_modules/.bin/eslint --fix --ignore-path .gitignore .

Якщо у вас є eslint сценарій попереднього тестування, ви також можете:

npm run pretest -- --fix

Однак існують певні класи проблем, які eslint не вирішить, і в цьому випадку може допомогти одноразове очищення з використанням prettier. prettier частіше використовується як альтернатива eslint, і установка для автоматичного форматування вихідного коду до його фіксації (цікавий, але не часто використовується підхід, що виходить за рамки цього блогу), але він також дуже корисний при початковому завантаженні eslint. Запустіть це так:

npm i prettier ./node_modules/.bin/prettier --single-quote --trailing-comma es5 --print-width 80 --write --no-bracket-spacing **/*.js

Після запуску eslint --fix та prettier у вас має залишитися дуже мало попереджень для очищення вручну. Хоча prettier не так часто використовується як інструмент, як eslint, при бажанні його можна використовувати як доповнення до eslint (prettier для автоматичного форматування, eslint для примусового форматування та перевірки помилок).Якщо з якоїсь причини у вас немає часу, щоб виправити це прямо зараз, вимкніть eslint правила. Набагато краще, щоб якесь підмножина стилів застосовувалося автоматично, ніж нічого. Ви можете перевизначити деякі стилі StrongLoop для конкретного проекту, а потім повернутися та очистити код, коли у вас буде час. Ось приклад ослаблення правила max-len, щоб дозволити рядки, що біжать, шириною до 120 символів:

Ви можете виявити, що код використовує єдиний стиль, але не стиль StrongLoop. Якщо він є близьким, ви можете налаштувати стиль StrongLoop і опублікувати його як свій власний. Якщо ваш стиль радикально відрізняється, має сенс просто написати та опублікувати свою власну повторно використовувану конфігурацію.

Як тільки ваш код буде чистим (перевірте за допомогою npm run pretest), зафіксуйте результат:

git commit -a -m 'Project lints clean'

Автоматизувати це

Існує два рівні автоматизації, політика в масштабах всього проекту та ваше особисте налаштування.

Щодо політики всього проекту, оскільки eslint налаштований для роботи з вашими тестами, робити більше нічого. Якщо ви не запускаєте тести для свого проекту автоматично, тоді настав час починати!

Що стосується моєї особистої настройки, я віддаю перевагу eslint запускався при кожному з моїх коммітів, тому будь-які проблеми, які я створюю, вловлюються на моїй машині, перш ніж вони будуть виявлені CI. Я роблю це за допомогою пастки "pre-commit". Щоб налаштувати це, використовуйте як основу гачок з прикладу:

cp .git/hooks/pre-commit.sample .git/hooks/pre-commit

Останні рядки файлу виглядатимуть так:

# Якщо є білийпростор, print the offending file names and fail. exec git diff-index --check --cached $against --

Змініть його так, щоб він виглядав так:

set -e npm run pretest # Якщо є білийпростор, print the offending file names and fail. exec git diff-index --check --cached $against --

Вітаю!

Ось і все, тепер ви ще один користувач eslint.

І працює з ESLint — JavaScript Linter, що підключається

Ця стаття була рецензована Тимом Северієном. Дякуємо всім рецензентам SitePoint за те, що зробили контент SitePoint якнайкраще!

Вам знайоме слово «лінтінг»? Це процес використання інструменту для автоматичної перевірки вашого коду на наявність потенційних проблем. Є кілька ключових переваг, які можна отримати від використання такого інструменту.

• Збереження вашого стилю коду узгодженим. Лінтери дозволяють вам перевіряти стиль коду на наявність проблем, таких як інтервали, відступи та розміщення фігурних дужок. Як тільки ваша команда погодиться зі стилем кодування, це може бути документовано у файлі конфігурації та перевірено автоматично.
• Виявлення потенційних помилок та поганих моделей. Лінтери також можуть бути використані для виконання більш складних перевірок, щоб виявити можливі помилки, такі як змінні, недоступний код або неприпустимі регулярні вирази. Попередження від лінтера дозволить вам виправити помилки ще до того, як вони досягнуть часу виконання.
• Забезпечення якості. Коли ви дотримуєтеся певного посібника за стилем у своєму проекті, важливо застосовувати його за допомогою інструментів, інакше завжди знайдуться люди, спокушені зрізати кути. Якщо в процес складання вбудований інструмент для малювання, ви можете просто заборонити запуск або фіксацію проекту у вашому сховищі, якщо є нефіксовані помилки.
• Економія часу Основна перевага попередніх трьох полягає в тому, що лінтери заощаджують ваші зусилля під час розробки. Вам більше не потрібно витрачати дорогоцінний час на суперечки з колегами про недоречну дужку, і ви можете виявити одну чи дві помилки на ранніх стадіях.

Вже була стаття про доступні лінтери для JavaScript, але сьогодні ми зосередимося на одному з інструментів, згаданих автором - ESLint.

ESLint

ESLint - це інструмент для малювання, створений ще в 2013 році Ніколасом К. Закасом, і в даний час він є найпотужнішим і розширюваним лінтером, доступним для JavaScript. Він надає багатий набір функцій, які роблять його ідеальним вибором для наступного інструменту для підкладки. Ці функції включають:

• Безліч правил, які можна додатково налаштувати на власний смак.
• API для створення власних правил.
• Численні плагіни з правилами для конкретних бібліотек, фреймворків та практик.
• Вбудована підтримка ES6, ES7 та JSX.
• Рекомендований набір правил, а також інші конфігурації, доступні для швидкого початку роботи.
• Може бути інтегрований із кількома редакторами та IDE, такими як Sublime, Vim, продукти JetBrains та Visual Studio Code.

Налаштування проекту

Перед тим, як впровадити ESLint у власні існуючі проекти, було б розумно спробувати його на чомусь простому. Давайте створимо тестовий проект, який ми використовуватимемо як майданчик для подальших досліджень. У ньому буде лише один файл JavaScript, необхідні модулі npm та пара команд npm для запуску linter.

Перш за все, ми створимо проект npm (якщо ви не впевнені в установці або використанні npm, див. цей посібник).Створіть нову папку, відкрийте її в терміналі та запустіть npm init . Вам буде запропоновано ввести деяку інформацію про ваш проект, і як тільки ви відповісте на всі запитання, npm створить новий файл package.json у тій самій папці.

Як тільки ми покінчили з npm, нам також знадобиться JavaScript для лінтингу. Давайте створимо scripts.js ім'ям scripts.js і збережемо там трохи коду:

function
doGood()

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

Вам не потрібен лінтер, щоб визначити деякі проблеми в коді. Але ми не хочемо чути це від вас чи від мене, а від самої ESLint.

Встановлення та налаштування

Для встановлення ESLint все, що вам потрібно зробити, це запустити npm i eslint --save-dev зсередини папки вашого проекту. Ми могли б встановити ESLint глобально, але я твердо переконаний, що кожен проект повинен пов'язувати свої власні залежності, щоб кожен розробник, який працює над проектом, використовував одні й самі інструменти.

Після встановлення ESLint нам потрібно налаштувати його перед першим запуском. Це зручно зробити, запустивши ESLint із прапором --init . Оскільки ESLint не встановлений глобально, команда буде виглядати так:

./node_modules/.bin/eslint --init

Ця команда запустить майстер налаштування. Майстер запропонує вам три способи створення конфігурації:

• Вибір відповіді на запитання про ваш стиль вимагатиме від вас відповіді на деякі питання про налаштування вашого проекту, наприклад, на яке середовище ви націлюєтеся, версію ECMAScript, модулі, використання CommonJS або JSX та деякі переваги стилю. Це швидкий спосіб налаштувати проект із мінімальним набором рекомендованих правил.
• Вибір « Використовувати посібник з популярних стилів» дозволить вам створювати свою конфігурацію на одному з найпопулярніших посібників зі стилів від Google, Airbnb та інших. Цей варіант добре працює, якщо ви вже використовуєте його або плануєте використовувати один із цих стилів
• Перевірте, що ваш файл JavaScript спробує вивести правила лінгвісту з існуючої кодової бази. Добре працює, коли у вас вже є кодова база, яку ви не захочете міняти.

Оскільки ми тільки починаємо новий проект, давайте виберемо перший варіант і підпишемося на новітні функції ECMAScript:

Останнє питання дозволить вам вибрати формат конфігураційного файлу. Можливі варіанти: JSON, YAML і JavaScript, але ми підемо з JSON, так як він, ймовірно, найбільш знайомий усім.

Після того, як ви відповісте на всі запитання, ESLint створить файл .eslint.json з таким вмістом:

"env":

"browser":
true,
"es6":
true
>,
"extends":
"eslint:recommended",
"parserOptions":

"sourceType":
"module"
>,
"rules":

"indent":
[
"error",
4
],
"linebreak-style":
[
"error",
"unix"
],
"quotes":
[
"error",
"Single"
],
"semi":
[
"error",
"always"
]
>
>

Як бачите, він містить деяку конфігурацію середовища, а також правила, про які він запитував вас. Для властивості extends встановлено значення eslint:recommended що означає, що ESLint буде використовувати власний набір рекомендованих правил як основу, яку можна пізніше перевизначити. Ми залишимо все як є для демонстраційних цілей, але пізніше ви можете видалити його, або замінити його іншим набором правил сторонніх виробників.

Запуск ESLint

Тепер, коли у нас є базова конфігурація, спробуємо запустити її і подивитися, чи працює вона.

Для запуску ESLint ми можемо використовувати наступну команду, яка збере всі файли .js у кореневій папці проекту:

./node_modules/.bin/eslint *.js

Щоб не вводити це в термінал, ми можемо зберегти його як скрипт npm. Відкрийте package.json і додайте ще один скрипт поруч із test.

"scripts":

"test":
"echo \"Error: no test specified\" && exit 1",
"lint":
"eslint *.js"
>,

Зверніть увагу, що нам не потрібно ./node_modules/.bin повний шлях до ./node_modules/.bin оскільки при запуску скриптів npm ця папка автоматично додається до PATH.

Ми можемо запустити його зараз, використовуючи

Іди та спробуй. Ви повинні побачити повідомлення про помилки, що попереджає нас про всі види проблем у scripts.js :

Не турбуйтеся, коли скрипт вузла повідомляє про помилку, це має статися, оскільки ESLint повернув ненульовий код завершення. При необхідності це можна придушити, додавши exit 0 у скрипт (як обговорено тут).

Тільки деякі правила включені в рекомендованому наборі. Там їх набагато більше.

Огляд правил

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, додавши наступний фрагмент коду в наш приклад:

Повторний запуск лінтера спричинить появу нових помилок:

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 Якщо ні, ви хотіли б спробувати?

Тримайте свій код чистим за допомогою ESLint

Основи популярного JavaScript лінтера, який дозволяє проводити аналіз якості твого коду.

ESLint – це лінтер для мови програмування JavaScript, написаний на Node.js.

Він надзвичайно корисний, тому що JavaScript, будучи мовою, що інтерпретується, не має етапу компіляції і багато помилок можуть бути виявлені тільки під час виконання.

• знайти існуючі помилки у коді;
• уникнути дурних помилок;
• уникнути нескінченні цикли за умов циклу for;
• переконається, що це методи getter повертають щось;
• не дозволити вирази console.log (та аналогічні);
• перевірити наявність дублікатів cases у switch;
• перевірити недоступний код;
• перевірити правильність JSDoc;

та багато іншого! Повний список доступний за посиланням.

Зростаюча популярність Prettier як засобу форматування коду зробила частину стилів ESLint застарілою, але даний лінтер все ще дуже корисний для виявлення помилок у коді.

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

Встановлення ESLint глобально

npm
install
-g eslint # створює конфігураційний файл `.eslintrc` eslint --init
# запускає ESLint перевірку вказаного файлу eslint yourfile.js

Встановлення ESLint локально

npm
install eslint --save-dev # створює конфігураційний файл `.eslintrc` ./node_modules/.bin/eslint --init
# запускає ESLint перевірку вказаного файлу ./node_modules/.bin/eslint yourfile.js

Встановлення стилів Airbnb

Однією з найпопулярніших налаштувань для лінтера є використання Airbnb JavaScript Style.

yarn
add
--dev eslint-config-airbnb

npm
install --save-dev eslint-config-airbnb

щоб встановити пакет конфігурації Airbnb і додай у свій .eslintrc файл який знаходиться в корені твого проекту:

// .eslintrc

"extends":
"airbnb"
>

Установка стилів для React

Підключити лінтер для React можна легко за допомогою плагіна React:

yarn
add
--dev eslint-plugin-react

npm
install --save-dev eslint-plugin-react

і додавши у свій файл .eslintrc:

// .eslintrc

"extends":
"airbnb",
"plugins":
["react"],
"parserOptions":

"ecmaFeatures":

"jsx":
true
>
>
>

Використовуйте конкретні версії EcmaScript

ECMAScript змінює свою версію щороку.

За замовчуванням встановлено 5-ту версію, що означає стандарт до 2015 року.

Щоб увімкнути ES6 (або вище), пропиши це в .eslintrc

// .eslintrc

"parserOptions":

"ecmaVersion":
6
>
>

Детальний посібник з правил можна знайти на офіційному сайті https://eslint.org/docs/user-guide/configuring.

Відключення правил, де це необхідно

Іноді тобі може знадобитися вимкнути правила у конкретному місці, це можна зробити так:

/* eslint-disable */
alert("test");
/* eslint-enable */

alert("test");
// eslint-disable-line

також можна вимкнути одне або кілька конкретних правил для кількох рядків:

/* eslint-disable no-alert, no-console */
alert("test"); console.log("test");
/* eslint-enable no-alert, no-console */

або для одного рядка:

alert("test");
// eslint-disable-line no-alert, quotes, semi