Как исправить ошибки eslint

Поскольку JavaScript — это интерпретируемый язык, ошибки, допущенные в коде, выявляются во время его выполнения. Чтобы увидеть ошибки до запуска кода, используется инструмент, который называется линтер. Для поиска ошибок применяется статический анализ и используются особые правила.

Что такое ESLint

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

Как работать с ESLint: шаг за шагом

Перед установкой ESLint нужно установить Node.js с поддержкой SSL и npm. Предположим, что вы уже сделали это заранее.

Для начала создайте каталог для проекта и поместите в него файл index.js с таким содержимым:

let i = 0;
do {
    alert( i );
    i++;

} while (true);

Затем инициализируйте npm в этом каталоге, если еще этого не сделали:

npm init

В результате будет создан файл package.json с параметрами пакета.

Установите ESLint в каталоге проекта. Для этого запустите в терминале следующую команду:

npm install eslint --save-dev

ESLint будет установлен локально. Существует возможность глобальной установки (с помощью команды npm install eslint --global), но не рекомендуем использовать такой подход. Все модули и совместно используемые файлы конфигурации в любом случае следует устанавливать локально.

Для настройки файла конфигурации выполните следующую команду:

npx eslint --init

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

Укажем, что будут использованы модули JavaScript:

В примере мы не используем ни React, ни Vue.js, ни TypeScript:

Предположим, код будет выполняться в браузере:

Укажем, что будем применять инструкции по стилю и выберем Airbnb:

Пусть файл конфигурации будет создан в формате JSON:

Установим зависимости:

В результате в каталоге проекта будет создан файл .eslintrc.json (или с другим расширением — в зависимости от выбранного вами формата).

В нем будет находиться примерно такой код:

module.exports = {
    'env': {
        'browser': true,
        'es2021': true
    },
    'extends': 'eslint:recommended',
    'parserOptions': {
        'ecmaVersion': 12,
        'sourceType': 'module'
    },
    'rules': {
    }
};

Проверяем проект

Теперь можно проверить проект, вызвав линтер для какого-либо файла или каталога. Вызовем eslint, передав в качестве аргумента текущий каталог (обозначенный точкой): node_modules.bineslint .

В результате получим:

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

В сообщении указано, что три ошибки можно исправить, указав опцию --fix. Давайте так и сделаем: введем ту же команду и укажем эту опцию:

node_modules.bineslint . --fix

Вывод будет таким:

Видим, что линтер сам справился с тремя ошибками, а нам оставил остальные. Код в файле изменен:

let i = 0;
do {
    alert(i);
    i++;

} while (true);

Обратите внимание: вставлен символ новой строки и убраны пробелы в скобках.

Rules: правила проверки кода

В конфигурации примера выше мы использовали имеющиеся правила проверки. Но можно добавить и свои правила. В файле .eslintrc.json есть раздел rules.

Если при создании проекта указать не имеющийся набор инструкций, а задать свои правила (выбрав пункт Answer questins about your style), то в разделе правил в файле .eslintrc.json можно будет увидеть примерно такие правила:

'rules': {
        'indent': [
            'error',
            4
        ],
        'linebreak-style': [
            'error',
            'unix'
        ],
        'quotes': [
            'error',
            'single'
        ],
        'semi': [
            'error',
            'always'
 ]
    }

Структура правила проста. Рассмотрим первое правило из приведенного выше примера.

Слово indent — это имя правила. Первый элемент в списке обозначает уровень ошибки и может принимать следующие значения:

• off или 0 — выключить правило;
• warn или 1 — включить правило как предупреждение (не влияет на код выхода);
• error или 2 — включить правило как ошибку (с кодом выхода 1).

Второй элемент в этом случае означает количество пробелов. Второй аргумент зависит от правила.

Итак, приведенные выше правила указывают, что следует использовать отступ в четыре пробела, завершение строк в стиле UNIX, одинарные кавычки и не пропускать точку с запятой.

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

• getter-return (обязательное применение оператора возврата в методах чтения);
• no-setter-return (запрет применения оператора возврата в методах изменения значения);
• no-dupe-args (запрет дублирующихся аргументов в определениях функций).

Есть правила проверки соблюдения передовой практики, например, accessor-pairs (обязательное применение пар методов чтения и изменения значений в объектах и классах).

Правила относительно переменных (no-unused-vars — запрет на неиспользуемые переменные), стилистические правила (eol-last — разрешение или запрет символа новой строки в конце файла) и правила для ECMAScript 6.

Вернемся к коду, немного изменим файл index.js и отправим его на проверку:

let i = 0
do {
    alert("Loop " + i);
    i++;

} while (true);

Будут выданы такие сообщения об ошибках:

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

Полный список правил ESLint можно просмотреть по этой ссылке.

Чтобы не вводить одни и те же команды каждый раз, можно в разделе scripts в файле package.json указать сценарий для запуска eslint. Он может выглядеть так:

"scripts": {

    "lint": "eslint . --fix"

  },

Вывод будет примерно таким:

Эти сообщения об ошибках можно проигнорировать.

Проверку можно отключать как для отдельных строк, так и для нескольких.

Для отключения отдельной строки ее нужно завершить комментарием:

// eslint-disable-line

Чтобы отключить проверку для нескольких строк, перед ними следует вставить комментарий /* eslint-disable */, а после — /* eslint-enable */:

let i = 0;

do {

    alert('Loop ' + i);

    i++;

/* eslint-disable */

} while (true);

/* eslint-enable */

Также можно отключить одно или несколько конкретных правил. Для этого в комментарии /* eslint-disable */ их перечисляют через запятую:

/* eslint-disable semi, quotes */

Заключение

ESLint — эффективный инструмент, который можно настраивать и расширять в соответствии с потребностями разных проектов.

ESLint продолжает активно развиваться и интегрируется с Sublime Text 3, Vim, Visual Studio Code, IntelliJ IDEA, Emacs, Eclipse и многими другими средами разработки.

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

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

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

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

Мы будем использовать husky для добавления git перехватчиков в наш проект. 

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

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

Мы используем Express generator для создания скелета приложения.

Теперь давайте его запустим при помощи следующих команд:

cd myapp
npm install
DEBUG=myapp:* npm start

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

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

npm install --save-dev eslint

Нам не стоит производить полную установку ESLint, достаточно будет инсталлировать его в качестве dev-зависимости. 

Для запуска конфигурации мы введем:

./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? Мы просто изменим его в нашем файле .eslintrc.json.

После этого ESLint больше не будет выдавать эту ошибку.

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

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

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

Читайте также:

• Основы JavaScript: управление DOM элементами (часть 1)
• 3 способа клонирования объектов в JavaScript
• Советы по анимации с CSS и JavaScript

Перевод статьи Tushar Tuteja: Using ESLint Right

Many React projects have ESLint set up and devs are fixing lint errors as they code. This is great for reducing bugs, and keeping code cleanly formatted.

However, sometimes there’s a situation where a project can have a lot of linting errors (i.e. adding ESLint to an existing project) and it would be tedious for a dev to fix them manually. Don’t worry, ESLint has a command for auto-fixing: eslint --fix!

In this article I’ll discuss the flags available for ‘fix’, the types of issues (problem, suggestion, layout) that ‘fix’ can resolve automatically, and options such as how to limit the amount of warnings, print to a file, and more.

Whether or not you have experience with ESLint, the primary thing you need to know for using ESLint commands is that it will only lint and fix according to the rules set in your .eslintrc.json file*. An .eslintrc.json file with lots of preconfigured rules can be found here at this ESLint playground (scroll to the bottom for the download).

Related: Test your TypeScript knowledge against these 50 difficult TypeScript questions.

*If you are running ‘fix’ from the eslint-cli, you can set rules with the --rule option.

There are three ways that ESLint fix can be run:

• eslint --fix
• eslint --fix-dry-run
• eslint --fix --fix-type

eslint --fix will fix every rule violation it is capable of fixing, actually overwrite the code, and print out any warnings or errors it was incapable of fixing.

Most errors are not actually automatically fixable. Take a look at this documentation, the items with the ‘wrench’ image can be auto-fixed.

Here’s an interesting example: 0 == 0 can be automatically fixed (to 0 === 0), but comparing a variable likely won’t be fixed (i.e. x == 0). The linter has to err on the side of caution. It generally fixes redundancies and situations where typing can be certain.

The output from eslint --fix will be a list of errors and warnings. If desired, warnings can be silenced with the --quiet flag. Conversely, if desired, a maximum number of errors can be specified as ‘too many’ (--max-warnings [number]), and the linter will succeed but end with exit code 1 (more on that below).

eslint --fix-dry-run acts like fix but will not actually overwrite the file. Instead, specify an output location and a formatting option such as eslint --fix-dry-run --format=json -o ./test.test.json. This output will be quite verbose, naming the files that were linted and results.

eslint --fix --fix-type enables targeting of specific categories of issues to fix. We’ll discuss the types in more detail below, but an example command would be eslint --fix --fix-type layout. This would fix an issue such as having too much whitespace before a line of code, if the rule is designated in your .eslintrc.json file (this rule in particular would be “indent”: [“error”, 4] to limit whitespace to four characters).

Below is output from my project when I ran eslint --fix --fix-type problem ”src/**/*.tsx” . This command targeted all problems in my .tsx files under src folder.

*A note on these commands: notice that--fix-type is preceded by -fix , while --fix-dry-run is not.

The Three Types of Fixable Issues

The three types of issue either fixed or reported by --fix are:

• problem
• suggestion
• layout

According to the ESLint documentation:

• a problem is code that will cause an error or confusion
• a suggestion is code that could be done in a better way
• layout deals with how the code looks

Now that we are familiar with the fix-type flag, let’s look again at the 0 == 0 issue. This is fixable as a suggestion. Issues such as whitespace count before the start of a code statement or extra parenthesis are fixable as layout.

ESLint –fix Warnings

When running eslint --fix, some rule violations result in warnings instead of errors. Take a look at the below TypeScript rule violations:

warning IObservableArray is defined but never used @typescript-eslint/no-unused-varswarning Unexpected any. Specify a different type @typescript-eslint/no-explicit-any

Generally, warnings don’t directly result in problems at runtime. However, many rules can be configured to show errors instead of warnings (or vice versa). For example, both of the issues listed above are included as warnings when extending @typescript-eslint/recommended like below in .eslintrc.json:

extends: [
  'plugin:@typescript-eslint/recommended'
]

However, I could have specified the below instead:

rules: [
  "no-unused-vars": "error"
]

This would make the IObservableArray violation appear as an error instead of a warning. Error vs warning is partly a difference in what rules a particular team finds most critical to enforce.

The Three Exit Codes of ESLint fix Command

ESLint’s fix command has three possible exit codes:

• 0: success and no lint errors, less warnings than max warnings
• 1: linting was successful, at least one lint error or more warnings than max-warnings
• 2: linting unsuccessful due to config error or internal error

The exit code will be at the end of the output and appear like this:

It’s best to fix the errors of course. However, keep in mind there is also the option (preferably only during testing) to ignore rules for individual lines. For example, // eslint-disable-next-line @typescript-eslint/no-explicit-any could be used to bypass the no-explicit-any warning mentioned previously.

TSLint –fix Differences

Even though TSLint is deprecated in favor of ESLint, many devs are still using TSLint (based on how many Google searches are still happening for TSLint topics).

TSLint has a --fix option, but it has no flags (i.e. no --dry-run option). TSLint also has different exit codes. From Palantir’s docs:

0: Linting succeeded without errors (warnings may have occurred)

1: An invalid command line argument or combination thereof was used

2: Linting failed with one or more rule violations with severity error

If you are still using TSLint, consider upgrading to typescript-eslint. Many of the commands and directives are the same, such as the directives for ignoring lines or rules.

Resources

Here’s how and when to specify global variables in your .eslintrc file.

Here’s how to configure the @typescript-eslint/ban-types rule in your project.

Expand your JavaScript knowledge with these 50 difficult JavaScript questions!

Normally I link to example React code and show screenshots of a working app. This article is different: the codebase doesn’t matter much, it’s all about the ESLint commands and the output. In addition to the code snippets and screenshots above, take a look at the below docs. They provide very detailed information about all the capabilities of ESLint fix.

• ESLint docs: https://eslint.org/docs/user-guide/command-line-interface#fixing-problems
• Old TSLint ‘fix’ command: https://palantir.github.io/tslint/usage/cli/
• This is a good start to your .eslintrc.json file:

parser: '@typescript-eslint/parser',
extends: [
  'eslint:recommended',
  'plugin:react/recommended',
  'plugin:@typescript-eslint/recommended'
],
plugins: [
  'react-hooks'
]

• This is an excellent resource: https://eslint.org/demo. You can scroll to the bottom and download the .eslintrc.json used for the rules in the demo. You likely will want to incorporate some of these rules in your own project.

Fixing problems

--fix

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

1. Эта опция вызывает ошибку,когда код передается в ESLint.
2. Эта опция не влияет на код,использующий процессор,если только процессор не разрешает автоисправление.

Если вы хотите исправить код из стандартного stdin или иным образом хотите получить исправления, не записывая их в файл, используйте параметр --fix-dry-run .

--fix-dry-run

Этот параметр имеет тот же эффект, что и --fix , с одним отличием: исправления не сохраняются в файловой системе. Это позволяет исправить код из stdin (при использовании с флагом --stdin ).

Поскольку форматер по умолчанию не выводит фиксированный код, вам придется использовать другой (например , json ), чтобы получить исправления. Вот пример этого шаблона:

getSomeText | npx eslint 

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

--fix-type

Этот параметр позволяет указать тип исправлений, которые следует применять при использовании --fix или --fix-dry-run . Есть четыре типа исправлений:

1. problem — исправить возможные ошибки в коде
2. suggestion — применить исправления к коду, которые улучшают его
3. layout — применить исправления, не меняющие структуру программы (AST)
4. directive — применить исправления к встроенным директивам, таким как // eslint-disable

В командной строке можно указать один или несколько типов исправлений.Приведем несколько примеров:

npx eslint --fix --fix-type suggestion .npx eslint --fix --fix-type suggestion --fix-type problem .npx eslint --fix --fix-type suggestion,layout .

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

Ignoring files

--ignore-path

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

Example:

npx eslint --ignore-path tmp/.eslintignore file.jsnpx eslint --ignore-path .gitignore file.js

--no-ignore

Отключает исключение файлов из .eslintignore , --ignore-path , --ignore-pattern и ignorePatterns в файлах конфигурации.

Example:

npx eslint --no-ignore file.js

--ignore-pattern

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

Example:

npx eslint --ignore-pattern '/lib/' --ignore-pattern '/src/vendor/*' .

Using stdin

--stdin

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

Example:

cat myfile.js | npx eslint --stdin

--stdin-filename

Эта опция позволяет указать имя файла для обработки STDIN как.Это полезно при обработке файлов из STDIN,и у вас есть правила,которые зависят от имени файла.

Example

cat myfile.js | npx eslint --stdin --stdin-filename=myfile.js

Handling warnings

--quiet

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

Example:

npx eslint --quiet file.js

--max-warnings

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

Обычно, если ESLint запускается и не находит ошибок (только предупреждения), он завершается с успешным статусом выхода. Однако, если --max-warnings и общее количество предупреждений превышает указанный порог, ESLint выйдет со статусом ошибки. Указание порога -1 или пропуск этой опции предотвратит такое поведение.

Example:

npx eslint --max-warnings 10 file.js

Output

-o, --output-file

Включите запись отчета в файл.

Example:

npx eslint -o ./test/test.html

При указании данный формат выводится в указанное имя файла.

-f, --format

Эта опция задает выходной формат консоли.Возможные форматы:

• checkstyle
• compact
• html
• jslint-xml
• json
• junit
• стильный (по умолчанию)
• tap
• unix
• visualstudio

Example:

npx eslint -f compact file.js

Вы также можете использовать пользовательскую батарею из командной строки,указав путь к файлу пользовательской батареи.

Example:

npx eslint -f ./customformat.js file.js

Установленный npm форматтер разрешается с eslint-formatter- или без него .

Example:

npm install eslint-formatter-prettynpx eslint -f pretty file.js

При указании заданного формата выводятся данные в консоль.Если вы хотите сохранить этот вывод в файл,вы можете сделать это в командной строке следующим образом:

npx eslint -f compact file.js > results.txt

Результат будет сохранен в файле results.txt .

--color, --no-color

Эта опция принудительно включает / выключает цветной вывод. Вы можете использовать это, чтобы переопределить поведение по умолчанию, которое состоит в том, чтобы включить цветной вывод, если не обнаружен TTY, например, при eslint через cat или less .

Examples:

npx eslint 

--no-inline-config

Этот параметр предотвращает любые действия встроенных комментариев, таких как /*eslint-disable*/ или /*global foo*/ . Это позволяет вам установить конфигурацию ESLint без изменения файлов. Все встроенные комментарии к конфигурации игнорируются, например:

• /*eslint-disable*/
• /*eslint-enable*/
• /*global*/
• /*eslint*/
• /*eslint-env*/
• // eslint-disable-line
• // eslint-disable-next-line

Example:

npx eslint --no-inline-config file.js

--report-unused-disable-directives

Эта опция заставляет ESLint сообщать о комментариях директивы, таких как // eslint-disable-line если в этой строке в любом случае не было бы сообщений об ошибках. Это может быть полезно для предотвращения непредвиденного подавления будущих ошибок путем очистки старых комментариев eslint-disable , которые больше не применимы.

Предупреждение : при использовании этой опции возможно, что новые ошибки начнут сообщаться при обновлении ESLint или пользовательских правил. Например, предположим, что в правиле есть ошибка, из-за которой оно сообщает о ложном срабатывании, и eslint-disable комментарий eslint-disable для подавления неверного отчета. Если ошибка затем будет исправлена ​​в выпуске патча ESLint, комментарий eslint-disable перестанет использоваться, поскольку ESLint больше не генерирует неверный отчет. Это приведет к новому сообщению об ошибке для неиспользуемой директивы, если report-unused-disable-directives опция report-unused-disable-directives .

Example:

npx eslint --report-unused-disable-directives file.js

Caching

--cache

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

Примечание. Если вы запустите ESLint с --cache , а затем запустите ESLint без --cache , файл .eslintcache будет удален. Это необходимо, поскольку результаты lint могут измениться и сделать .eslintcache недействительным. Если вы хотите контролировать, когда файл кеша удаляется, используйте --cache-location , чтобы указать альтернативное расположение для файла кеша.

Примечание. Файлы с автофиксацией не помещаются в кеш. Последующий линтинг, который не запускает автоисправление, поместит его в кеш.

--cache-file

Путь к файлу кеша. Если не указан .eslintcache будет использоваться. Файл будет создан в каталоге, где eslint команда eslint . Не рекомендуется : используйте вместо этого --cache-location .

--cache-location

Путь к расположению кеша. Может быть файлом или каталогом. Если местоположение не указано, будет использоваться .eslintcache . В этом случае файл будет создан в каталоге, в котором eslint команда eslint .

Если указан каталог, в указанной папке будет создан файл кеша. Имя файла будет основано на хеш-коде текущего рабочего каталога (CWD). например: .cache_hashOfCWD

Важное примечание: если каталог для кеша не существует, убедитесь, что вы добавили конечный / on * nix systems или in windows. В противном случае путь будет считаться файлом.

Example:

npx eslint "src*.js" --cache --cache-location "/Users/user/.eslintcache/"

--cache-strategy

Стратегия использования кеша для обнаружения измененных файлов. Могут быть либо metadata либо content . Если стратегия не указана, будут использоваться metadata .

content стратегия может быть полезна в тех случаях , когда время модификации файлов изменится , даже если их содержание нет. Например, это может произойти во время операций git, таких как git clone, потому что git не отслеживает время изменения файла.

Example:

npx eslint "src*.js" --cache --cache-strategy content

Miscellaneous

--init

Эта опция запустит npm init @eslint/config , чтобы запустить мастер инициализации конфигурации. Он разработан, чтобы помочь новым пользователям быстро создать файл .eslintrc, ответив на несколько вопросов, выбрав популярное руководство по стилю.

Полученный конфигурационный файл будет создан в текущем каталоге.

--env-info

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

--no-error-on-unmatched-pattern

Эта опция предотвращает ошибки, когда шаблон глобуса в кавычках или --ext не имеет соответствия. Это не предотвратит ошибки, когда ваша оболочка не может сопоставить глобус.

--exit-on-fatal-error

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

--debug

Эта опция выводит отладочную информацию на консоль. Эта информация полезна, когда вы видите проблему и вам трудно ее точно определить. Команда ESLint может запросить эту отладочную информацию, чтобы помочь устранить ошибки. Добавьте этот флаг в вызов командной строки ESLint, чтобы получить дополнительную отладочную информацию при выполнении команды (например npx eslint --debug test.js и npx eslint test.js --debug эквивалентны)

-h, --help

Эта опция выводит меню помощи,отображая все доступные опции.Все остальные опции при их наличии игнорируются.

-v, --version

Эта опция выводит текущую версию ESLint на консоль.Все остальные опции при их наличии игнорируются.

--print-config

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

Example:

npx eslint --print-config file.js

Игнорирование файлов из подшивки

ESLint поддерживает файлы .eslintignore для исключения файлов из процесса линтинга, когда ESLint работает с каталогом. Файлы, указанные как отдельные аргументы CLI, не будут исключены. Файл .eslintignore представляет собой обычный текстовый файл, содержащий по одному шаблону в строке. Он может находиться в любом из предков целевого каталога; это повлияет на файлы в содержащем его каталоге, а также на все подкаталоги. Вот простой пример файла .eslintignore :

temp.js**/vendor/*.js

Более подробную разбивку поддерживаемых шаблонов и каталогов, которые ESLint игнорирует по умолчанию, можно найти в Ignoring Code .

Exit codes

При перетаскивании файлов ESLint выходит с одним из следующих кодов выхода:

• 0 : Линтинг прошел успешно, ошибок линтинга нет. Если флаг --max-warnings установлен в n , количество предупреждений о линтинге не превышает n .
• 1 : Линтинг прошел успешно, и есть хотя бы одна ошибка линтинга, или имеется больше предупреждений линтинга, чем разрешено параметром --max-warnings .
• 2 : Линтинг не удался из-за проблемы конфигурации или внутренней ошибки.

ESLint

8.30

yoda

Требовать или запрещать условия «Йода» Некоторые проблемы, о которых сообщает это правило, автоматически устраняются с помощью параметра командной строки. Условия Йоды названы так.

Интерфейс командной строки

Для установки ESLint требуется Node.js.

Configuration Files

ESLint supports configuration files several formats: If there are multiple configuration files in same directory, ESLint will only use one.

Using a configuration from a plugin

A plugin is an npm package that can add various extensions to ESLint.