Eslint fix как использовать

Найти и предотвратить ошибки в JavaScript: как быстро научиться работать с ESLint

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

Експертний курс від laba: Стратегічний маркетинг.
Розвивайте бізнес з глибоким пониманням ринку.

Что такое ESLint

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

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

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

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

let i = 0; do < alert( i ); i++; >while (true);

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

Інтенсивний курс від laba: Project Manager.
Ведіть проекти до успішного завершення.

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

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

npm install eslint —save-dev

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

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

npx eslint —init

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

Обозначения, зачем мы используем ESLint

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

Использование модулей JavaScript

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

Отмечаем, что не используем React и Vue.js

Отмечаем, что не используем TypeScript

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

Указываем, что код будет выполняться в браузере

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

Указываем, что хотим использовать инструкцию по популярным стилям

Для примера выбираем Airbnb

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

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

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

Інтенсивний курс від laba: Product management.
Від ідеї до успішного продукту.

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

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

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

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

На консоли — четыре ошибки и два предупреждения

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

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

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

Три ошибки исправлены

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

let i = 0; do < alert(i); i++; >while (true);

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

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

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

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

Творчий курс від skvot: 3D-художник персонажів.
Створюйте світ персонажів.
‘rules’:

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

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

• off или 0 — выключить правило;
• warn или 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 */ , а после — /* 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 и многими другими средами разработки.

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

Сложно о простом: ESLint в команде

Маленькое введение. Скорее всего этот пост будет интересен только тем, кто знает, что такое ESLint, но всё же сделаю небольшую вводную — а то сам сильно расстраиваюсь, когда открываю публикацию, и она начинается словами “уже 10 лет мы используем ххх, о котором вы конечно же знаете, а написать мы решили про xxx.yyy, что никто никогда не делал, но наверняка это очень круто”.

Итак, ESLint это крутой инструмент, который позволяет проводить анализ качества вашего кода, написанного на любом выбранном стандарте JavaScript. Он приводит код к более-менее единому стилю, помогает избежать глупых ошибок, умеет автоматически исправлять многие из найденных проблем и отлично интегрируется со многими инструментами разработки (привет, Jetbrains, мы любим вас!). Кстати, он, как и другие линтеры, не обязывает вас к одному какому-то конкретному стилю. Наоборот — вы можете выбрать что-то из лучших практик и доработать по своему усмотрению!

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

В общем, жить без линтера в Node.JS в 2017 году — это всё равно что писать код в notepad, при этом сидя на одной руке.

А сегодня я расскажу вам, как мы решили его внедрить, чтобы эффективно работать с ним в команде, а не по одиночке.

Большие ребята делают проверку линтером как часть процесса их CI, и мы до этого скоро дойдём. Но пока что нам нужно реализовать первичную необходимость — запуск линтера у разработчика, с гарантией, что всё взлетит и будет работать более-менее одинаково.

Казалось бы — что такого, добавляешь .eslintrc.json в проект, и поехали! Однако возникает вопрос — а как, куда и кем должен ставиться ESLint и пачка необходимых для нашего code style плагинов? Обычно для этого используется три подхода:

1. Давайте положим их в devDependency;
2. Давайте никуда их не положим. Пускай у каждого будет глобально стоять mocha\eslint\прочее.
3. Пускай всё ставить и прогонять проверки будут таск менеджеры вроде gulp или grunt.

Третий вариант неплох, но до сих пор мы как-то обходились без таск менеджеров. Добавлять их в проекты ради такой задачи это явный overkill.

Первый вариант в целом является оптимальным для проектов на гитхабе, но плохо подходит для коммерческой разработки. Наш CI предусматривает проведение автотестов на тестовых серверах, а тестовые зависимости прописать кроме devDependencies просто некуда. Но проблема не в этом, а в том, что, в отличие от автотестов, инструменты для линтера не должны попадать на тестовые сервера. Хотя бы по той причине, что тогда проект при раскатке резко начинает весить 200 с лишним мегабайт вместо 30. Кому-то это может показаться незначительным, но для соблюдения PCI DSS стандартов у нас повсеместно используется довольно серьёзное шифрование любой информации, так что раскатка обновления на 200 мегабайт занимает драгоценные минуты. Так что первый вариант нас тоже не устраивает. Подытожим:

• Линтер и его плагины не должны стоять глобально;
• Конкретный проект должен иметь привязки к конкретным версиям инструментов;
• Эти инструменты не должны быть ни в dependencies, ни в devDependencies.

Из спецификации package.json вспоминаем, что есть такая довольно странная и редко используемая секция, как peerDependencies:

In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a require of this host. This is usually referred to as a plugin. Notably, your module may be exposing a specific interface, expected and specified by the host documentation.

Автоматически они не ставятся, за исключением небольшого подводного камня:

NOTE: npm versions 1 and 2 will automatically install peerDependencies if they are not explicitly depended upon higher in the dependency tree. In the next major version of npm (npm@3), this will no longer be the case. You will receive a warning that the peerDependency is not installed instead. The behavior in npms 1 & 2 was frequently confusing and could easily put you into dependency hell, a situation that npm is designed to avoid as much as possible.

К счастью, npm у нас был уже не 2ой, так что можно было смело использовать данную секцию, не опасаясь внезапных последствий. Но проблема пришла откуда не ждали… Оказалось, что при удалении автоматической установки peerDependencies, авторы npm… Не сделали никакого способа поставить их вручную. Так что всё, что сейчас есть для секции peerDependencies — это предупреждение о том, что они не установлены. Отчасти эти объяснимо, поскольку зависимости эти опциональны, но всё же. У меня есть подозрение, что после такого изменения все разработчики просто перенесли всё в devDependencies… И dependency hell никуда не делся.
Кстати, не одному мне отсутствие такой опции показалось странным. Есть даже issue по этому поводу — она закрыта, но помечена как patch-welcome. То есть авторы npm в целом согласны, что это косяк — просто у них не хватает времени на исправление…

Итак, у нас теперь есть секция, но непонятно, как её использовать. 18 лайков той же самой issue есть на вот такое решение:

 npm info . peerDependencies | sed -n 's/^[[:space:]]*'\''\\([^:'\'']*\)'\''\:[[:space:]]'\''\([^'\'']*\).*$/\1@\2/p' | xargs npm i

По-моему, ад. Как тимлид, я просто не могу позволить, чтобы такое пришло в наши проекты…

В общем, дальше идея пошла в сторону написания или нахождения инструмента, который сам умеет парсить package.json и вызывать npm install — но не так жёстко, как скрипт, описанный выше. Более-менее менее меня удовлетворил npm-install-peers. Минуса у него два:

1. Если он по какой-то причине не находит установленный в системе npm (через который его сейчас вообще-то ставят), то он… Ставит его заново локально, что вызывает расход времени, трафика, и иногда всякие адовые ошибки.
2. Он не поддерживает какие бы то ни было аргументы. Если симлинки на windows уже можно включить, и —no-bin-links уже не очень актуален, то —production всё же хочется. Для тех же зависимостей линтера это бы сильно сэкономило время установки.

Дальше встаёт вопрос — а как собственно глобально ставить npm-install-peers? Считать, что он есть по умолчанию? Ставить молча при выполнении скрипта? Ставить локально в devDependencies? Мне ни один из вариантов не понравился. В результате удовлетворился вот таким простым решением:

"lint-install": "npm-install-peers || echo 'Please run npm install -g npm-install-peers first'",

Такой вариант мне показался наиболее прозрачным для разработчика.

И всё, что остаётся — добавить скрипт для запуска линтера и собственно нужные нам peerDependencies. Скрипт:

 "lint": "./node_modules/eslint/bin/eslint.js app.js routes modules test App.js" 

 "peerDependencies":

Кстати, как побочную фичу, мы теперь можем вынести в peerDependencies всякие прочие зависимости, которые не относятся к тестам — например, божественный jsdoc-to-markdown.

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

ESLint

WebStorm integrates with ESLint which brings a wide range of linting rules that can also be extended with plugins. WebStorm shows warnings and errors reported by ESLint right in the editor, as you type. With ESLint, you can also use JavaScript Standard Style as well as lint your TypeScript code.

Besides JavaScript and TypeScript, ESLint can be applied to files of other types in the entire project or in its specific parts, refer to Configure linting scope.

Before you start

1. Make sure you have Node.js on your computer.
2. Configure a Node.js interpreter in your project as described in Configuring a local Node.js interpreter, or in Using Node.js on Windows Subsystem for Linux, or in Configuring remote Node.js interpreters.

Install ESLint

1. In the embedded Terminal ( Alt+F12 ) , type one of the following commands:
   • npm install —g eslint for global installation.
   • npm install —save-dev eslint to install ESLint as a development dependency.
2. Optionally, install additional plugins, for example, eslint-plugin-react to lint React applications.

Activate and configure ESLint in WebStorm

By default, ESLint is disabled. You can choose to configure it automatically or specify all the configuration settings manually.

Configure ESLint automatically

With automatic configuration, WebStorm uses the ESLint package from the project node_modules folder and the .eslintrc.* configuration file from the folder where the current file is stored. If no .eslintrc.* is found in the current file folder, WebStorm will look for one in its parent folders up to the project root.

If you have several package.json files with ESLint listed as a dependency, WebStorm starts a separate process for each package.json and processes everything below it. This lets you apply a specific ESLint version or a specific set of plugins to each path in a monorepo or a project with multiple ESLint configurations.

• To configure ESLint automatically in the current project, open the Settings dialog ( Control+Alt+S ), go to Languages & Frameworks | JavaScript | Code Quality Tools | ESLint , and select the Automatic ESLint configuration option.
• To configure ESLint automatically in all new projects, open the Settings for New Projects dialog ( File | New Projects Setup | Settings for New Projects ) , go to Languages & Frameworks | JavaScript | Code Quality Tools | ESLint , and select the Automatic ESLint configuration option.

Configure ESLint manually

With manual configuration, you can use a custom ESLint package, configuration file, and working directories, as well as apply various additional rules and options.

1. In the Settings dialog ( Control+Alt+S ), go to Languages & Frameworks | JavaScript | Code Quality Tools | ESLint , and select Manual ESLint configuration .
2. In the ESLint package field, specify the location of the eslint or standard package.
3. In the Working directories field, specify the working directories for the ESLint process. By default the field is empty and WebStorm detects the working directory automatically. First it looks for a directory closest to the linted file which contains a .eslintignore or .eslintrc.* file, or a package.json file with either a eslintIgnore or a eslintConfig property. If the auto-detected working directory doesn’t match your project configuration, you need to specify the working directory (directories) manually. Use semicolons as separators. The acceptable values are:
   • Absolute paths.
   • Paths relative to the project base directory (the parent folder of the .idea folder where WebStorm-specific project metadata is stored). For example:
     1. ./ : use the project base directory as the ESLint process working directory.
     2. client;server : use /client and /server as working directories. For files that are neither under the client not under the server folder, the working directory will be auto-detected as described above.
     3. packages/* : each subfolder of the /packages directory will be used as the working directory for the corresponding linted files.
     • Automatic search : select this option if ESLint rules are configured in a package.json or in a .eslintrc.* file. This can be a .eslintrc , .eslintrc.json , or .eslintrc.yaml file, or a file in another supported format. For more information, refer to the ESLint official website. WebStorm looks for a .eslintrc.* file or for a eslintConfig property in a package.json . WebStorm starts the search from the folder where the file to be checked is stored, then searches in its parent folder, and so on until the project root is reached.
     • Configuration File — select this option to use a custom file and specify the file location in the Path field.

     Learn more about configuring ESLint from the ESLint official website.

     • In the Extra eslint options field, specify additional command-line options to run ESLint with, use spaces as separators. Learn more about ESLint CLI options from the ESLint official website.
     • In the Additional rules directory field, specify the location of the files with additional code verification rules. These rules will be applied after the rules from package.json , .eslintrc.* , or a custom configuration file and accordingly will override them. See the ESLint official website for more information about ESLint configuration files and adding rules.

     Configure linting scope

     1. Open the Settings dialog ( Control+Alt+S ), go to Languages & Frameworks | JavaScript | Code Quality Tools | ESLint , and select Automatic ESLint configuration or Manual ESLint configuration .
     2. In the Run for files field, specify the pattern that defines the set of files to be linted. You can accept the default pattern or type a custom one. With the default pattern, <**/*,*>. , ESLint will wake up and process any updated JavaScript, TypeScript, JSX, TSX, HTML, or Vue file. To lint files of other types or files stored in specific folders, use glob patterns to update the default pattern.
     3. For example, to automatically reformat CoffeeScript files as well, add coffee to the default pattern as follows:

     

     To lint files from a specific folder, replace <**/*,*>with * . Suppose, you have a project with the following structure: To lint only the files in the coffee folder, update the pattern as follows:

     Fix problems automatically on save

     ESLint can fix the detected problems every time your changes are saved either manually, with Control+S , or automatically, when you launch a run/debug configuration, or close WebStorm, or perform version control actions For more information, refer to Autosave.

     • Open the Settings dialog ( Control+Alt+S ), go to Languages & Frameworks | JavaScript | Code Quality Tools | ESLint , and select the Run eslint —fix on save checkbox.

     Enabling this option also enables Run eslint —fix in Settings | Tools | Actions on Save .

     Lint your code

     When installed and enabled, ESLint activates automatically every time you open a JavaScript file.

     By default, WebStorm marks detected problems based on the severity levels from the ESLint configuration. See Configuring ESLint highlighting to learn how to override these settings.

     Descriptions of the errors detected in the current file and quick-fixes for them are available from the editor and from the File tab of the Problems tool window.

     Errors in all previously opened files and quick-fixes for them are shown in the Project Errors tab of the Problems tool window. To open the tool window, click the Inspection widget in the upper-right corner of the editor:

     

     View problems and apply quick-fixes in the editor

     • To view the description of a problem, hover over the highlighted code. To resolve the detected problem, click ESLint: Fix » or press Alt+Shift+Enter . To resolve all the detected problems in the current file, click More actions ( Alt+Enter ) and select ESLint: Fix current file from the list. For more information, refer to View problems and apply quick-fixes in the editor.
     • Alternatively open the File tab of the Problems tool window Alt+6 , where you can view problem descriptions, apply quick-fixes, navigate to the fragments in the source code where errors occurred, as well as fix them in the Editor Preview pane without leaving the tool window. Learn more from Problems tool window.
     • You can also configure ESLint to fix all the problems in a file when this file is saved. To configure such behavior, select the Run eslint —fix on save checkbox on the ESLint page of the Settings dialog as described in Activating and configuring ESLint in WebStorm.

     Lint your code in the Problems tool window

     To open the Problems tool window, click the Inspections widget in the upper-right corner of the editor.

     

     Alternatively select View | Tool windows | Problems from the main menu or press Alt+6 .

     The Project Errors tab shows the errors in all files that were opened during the current session, with error messages grouped by files in which they were detected.

     

     Here you can view problem descriptions, apply quick-fixes, navigate to the fragments in the source code where errors occurred, as well as fix them in the Editor Preview pane without leaving the tool window. Learn more from Problems tool window.

     Configure highlighting for ESLint

     By default, WebStorm marks the detected errors and warnings based on the severity levels from the ESLint configuration. For example, errors are highlighted with a red squiggly line, while warnings are marked with a yellow background. For more information, refer to Code inspections and Change inspection severity.

     Change the severity level of a rule in the ESLint configuration

     • In .eslintrc or under eslintConfig in package.json , locate the rule you want to edit and set its ID to 1 warn or to 2 error . Learn more from the ESLint official website.

     You can override the severities from the ESLint configuration so that WebStorm ignores them and shows everything reported by the linter as errors, warnings, or in a custom color.

     Ignore the severity levels from the configuration

     

     1. In the Settings dialog ( Control+Alt+S ), select Editor | Inspections . The Inspections page opens.
     2. In the central pane, go to JavaScript | Code quality tools | ESLint .
     3. In the right-hand pane, clear the Use rule severity from the configuration file checkbox and select the severity level to use instead of the default one.

     Import code style from ESLint

     You can import some of the ESLint code style rules to the WebStorm JavaScript code style settings. That enables WebStorm to use more accurate code style options for your project when auto-completing, generating, or refactoring the code or adding import statements. When you use the Reformat action, WebStorm will then no longer break properly formatted code from the ESLint perspective.

     WebStorm understands ESLint configurations in all official formats: .eslintrc JSON files, package.json files with the eslintConfig field, as well as JavaScript and YAML configuration files.

     • When you open your project for the first time, WebStorm imports the code style from the project ESLint configuration automatically.
     • If your ESLint configuration is updated (manually or from your version control), open it in the editor and choose Apply ESLint Code Style Rules from the context menu. Alternatively, just answer Yes to the «Apply code style from ESLint?» question on top of the file. The list of applied rules is shown in the Event log tool window:

     Use JavaScript Standard Style

     You can set JavaScript Standard Style as default JavaScript code style for your application so its main rules are applied when you type the code or reformat it. Since Standard is based on ESLint, you can also use Standard via the WebStorm ESLint integration.

     Install JavaScript Standard

     • In the embedded Terminal ( Alt+F12 ) , type: npm install standard —save-dev Learn more from the JavaScript Standard Style official website.

     Enable linting with Standard via ESLint

     If you open a project where standard is listed in the project’s package.json file, WebStorm enables linting with Standard automatically.

     1. In the Settings dialog ( Control+Alt+S ), go to Languages & Frameworks | JavaScript | Code Quality Tools | ESLint .
     2. On the ESLint page that opens, select Manual ESLint configuration and specify the location of the standard package in the ESLint Package field.

     Set the JavaScript Standard Style as default

     1. In the Settings dialog ( Control+Alt+S ), go to Editor | Code Style | JavaScript .
     2. On the JavaScript page, click Set from , and then select JavaScript Standard Style . The style will replace your current scheme.

     ESLint with Docker

     With WebStorm, you can run ESLint against your code inside a Docker container just in the same way as you do it locally.

     1. Make sure the Node.js , Node.js Remote Interpreter , and Docker required plugins are enabled on the Settings | Plugins page, tab Installed . For more information, refer to Managing plugins.
     2. Download, install, and configure Docker as described in the Docker topic.
     3. Configure a Node.js remote interpreter in Docker or via Docker Compose and set it as default in your project. Also make sure the package manager associated with this remote interpreter is set as project default.
     4. Open your package.json and make sure ESLint is listed in the devDependencies section:

     < "name": "node-express", "version": "0.0.0", "private": true, "dependencies": < "cookie-parser": "~1.4.4", "debug": "~2.6.9", "express": "~4.16.1", "http-errors": "~1.6.3", "morgan": "~1.9.1", "pug": "^3.0.2" >, «devDependencies»: < "eslint": "^8.1.0" >>

     

   • Right-click anywhere in the editor and select Run ‘ install’ from the context menu.
   • After that, ESLint works in the same way as when you work with your code locally. View descriptions of detected discrepancies right in the editor or in the Problems tool window and apply suggested quick-fixes.

Линтер ES Lint

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

ESLint в терминале

Если у вас пока нет ESLint, его нужно установить из npm.

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

npm run lint 

ESLint показывает, что нашёл 6 ошибок в файле main.js . Цифры слева говорят на какой строке, на каком символе, была найдена ошибка. Дальше в строке идёт описание ошибки. Например:

Текст 5 errors and 0 warnings potentially fixable with the —fix option после списка ошибок говорит о том, что пять из шести найденных ошибок ESLint сможет исправить автоматически.

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

Исправление ошибок

Для исправления ошибок у ESLint есть опция fix . Чтобы воспользоваться этой опцией, выполним в терминале команду

npm run lint -- --fix 

Ключ —fix говорит о том, что мы хотим исправить ошибки автоматически, а два подчёркивания — перед ключом помогают понять терминалу, что ключ относится не к команде npm run lint , а к тому, что за ней скрывается — к eslint .

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

ESLint в редакторе

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

Установка расширения для ESLint в VS Code

Расширение для ESLint в VS Code может попросить подтвердить его запуск, если пакет eslint установлен локально (наш случай). Когда расширение спросит, откуда брать пакет eslint , нужно нажать «Allow», чтобы разрешить использовать eslint в текущем проекте.

С помощью расширения для ESLint в редакторе можно автоматически исправить ошибки. Для этого нужно навести на подсвеченную ошибку, нажать кнопку Quick fix во всплывающем окошке и выбрать один из предложенных вариантов. Например, можно исправить только конкретную ошибку, а можно и все доступные разом. Если ошибка не может быть автоматически исправлена, вместо кнопки Quick fix появится текст No quick fixes available или будут предложены альтернативные варианты решения.

Установка расширения для ESLint в Atom

В Atom тоже требуется специальное расширение linter-eslint для работы ESLint. Чтобы в Atom установить расширение, нужно перейти в раздел настроек «Install Packages». Открыть его можно из окна команд (сочетание клавиш Ctrl + Shift + P на Windows и Command + Shift + P на macOS), введя в поиске «Install Packages».

Также нужный раздел настроек можно открыть через меню: Edit → Preferences → Install — на Windows, Atom → Preferences → Install — в macOS.

Далее ищем нужное расширение и устанавливаем его:

После установки расширения может появиться всплывающее окно с предложением установить нужные зависимости, то есть другие расширения, с помощью которых работает linter-eslint . Для правильной работы линтера нужно установить все предложенные зависимости.

Теперь можно приступить к исправлению ошибок, исправить большинство ошибок можно автоматически, наведя на ошибку и нажав «Fix» или снова использовать окно команд, где выполнить Linter Eslint: Fix File .

Включение поддержки ESLint в WebStorm

В WebStorm не нужно устанавливать отдельное расширение, ESLint работает в этом редакторе «из коробки», достаточно только включить поддержку ESLint. Откройте окно Preferences с настройками, перейдите на вкладку ESLint (Languages and Frameworks → JavaScript → Code Quality Tools → ESLint) и выберете автоматическую конфигурацию ESLint — Automatic ESLint configuration. При автоматической конфигурации ESLint всегда будет искать в директории проекта файл .eslintrc с правилами оформления кода и ориентироваться на него.

Исправляются ошибки так же просто, достаточно нажать правой кнопкой мыши в файле с ошибками и выбрать из списка «Fix ESLint problems».

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.