Как настроить исправление eslint при сохранении vs code

Затем вы увидите такой вопрос:

✔ How would you like to define a style for your project? …

❯ Use a popular style guide

Answer questions about your style

Inspect your JavaScript file(s)

Выберите ответ Use a popular style guide.

Which style guide do you want to follow?

Ответьте Airbnb: https://github.com/airbnb/javascript.

Затем будет такой вопрос:

? What format do you want your config file to be in? …

Нужно выбрать JSON.

Вы получите такое сообщение:

Checking peerDependencies of eslint-config-airbnb-base@latest

The config that you’ve selected requires the following dependencies:

eslint-config-airbnb-base@latest eslint@^5.16.0 || ^6.8.0 || ^7.2.0 eslint-plugin-import@^2.21.2

Последний вопрос программы выглядит так:

? Would you like to install them now with npm? › No / Yes

Выберите вариант Yes, чтобы установить зависимости с помощью npm.

Вам также будет предложено установить дополнительные пакеты. Выберите yes.

После всех вопросов вы заметите, что в ваш каталог linting был добавлен файл .eslintrc.json. Теперь инструмент ESLint установлен. Код в app.js пока не изменился – и это связано с тем, что ESLint необходимо интегрировать с Visual Studio Code.

3: Настройка ESLint

Чтобы интегрировать ESLint в Visual Studio Code, вам необходимо установить расширение ESLint для VS Code. Вернитесь в Visual Studio Code и найдите ESLint во вкладке Extensions. После того, как вы найдете это расширение, нажмите Install.

После установки расширения ESLint вы заметите красочное подчеркивание в файле app.js – это линтер выделил ошибки в файле. Отметки в ESLint имеют разные цвета в зависимости от степени серьезности. Если вы наведете курсор на подчеркнутый код, вы увидите сообщение, объясняющее вам ошибку. Таким образом, ESLint помогает находить ошибки в коде и устранять их.

ESLint может сделать для вас даже больше: к примеру, он может автоматически исправлять ошибки при каждом сохранении файла (для этого требуется отдельная настройка).

4: Форматирование при сохранении

Чтобы ESLint мог автоматически исправлять синтаксис и устранять ошибки форматирования при каждом сохранении, вам нужно открыть меню настроек. Меню в Visual Studio Code – это значок шестеренки в левом нижнем углу. Нажмите его и выберите Settings.

В меню настроек найдите Code Actions on Save. Первой идет опция Editor: Code Actions on Save, а ниже – Edit in settings.json, и как раз она нам нужна.

Файл settings.json откроется в редакторе кода. Чтобы ESLint исправлял ошибки при сохранении файла, вам нужно добавить следующий код в settings.json:

С помощью этого кода ESLint сможет автоматически исправляет ошибки и проверяет JavaScript при сохранении.

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

• Теперь одинарные кавычки использованы последовательно.
• Точки с запятой – тоже.
• Отступ внутри функции расставлены правильно.

ESLint автоматически будет устранять синтаксические ошибки при сохранении файла app.js. Но пока у нас еще остались сообщения об ошибках. Их можно исправить, настроив ESLint для обнаружения или игнорирования определенных ошибок и проблем с форматированием.

5: Пользовательская настройка ESLint

«Из коробки» ESLint подчеркивает все операторы console.log() в app.js. В некоторых случаях распознавание операторов console.log в качестве ошибки может быть не в приоритете. Вы можете игнорировать операторы console.log.

Правила конфигурации ESLint можно изменить в файле .eslintrc.json.

Откройте файл .eslintrc.json. В этом файле вы увидите такой код:

В конце файла .eslintrc.json вы увидите объект «rules». Чтобы настроить триггеры ESLint (или отключить реакцию ESLint на определенные фрагменты кода), нужно добавить пары «ключ-значение» к объекту «rules». Ключ – это название правила, которое нужно добавить или изменить. Значение задает уровень серьезности проблемы. ESLint поддерживает три уровня серьезности:

• error – подчеркивается красным
• warn – подчеркивается желтое
• off – ничего неподчеркивается.

Если вы не хотите подчеркивать операторы console.log как ошибки, вы можете назвать правило no-console и указать это имя в качестве ключа. Используйте off как значение:

Это правило удаляет подчеркивание операторов console.log в app.js.

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

Если теперь вы включите в код одинарные кавычки, ESLint выдаст ошибку.

Заключение

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

Если вам нужна дополнительная информация о правилах и о том, какие пары «ключ-значение» вы можете использовать для настройки ESLint, вы можете ознакомиться с документацией.

Источник

Не удается получить правильный автоформат при сохранении в коде Visual Studio с ESLint и Prettier

в коде Visual Studio с ESLint и красивее при работе с файлами .vue, похоже, я не могу заставить vue/max-attributes-per-line автоматически исправляться правильно.

Например, если vue/max-attributes-per-line установлен в положение «off», и я пытаюсь добавить разрывы строк вручную, он исправляет его так, чтобы каждый элемент всегда находился не более чем в одной строке, независимо от того, имеет ли он ширину 81, 120, 200 или более символов. Как я могу понять, что заставляет мои элементы разметки помещаться ровно в одну строку?

Я использую ESLint версии 5.1.0 и Visual Studio Code (без расширения Prettier), с Prettier 1.14.2.

Вот пример в файле .vue — я не могу сделать это на нескольких строках, что бы я ни делал, когда ‘vue/max-attributes-per-line’: ‘off’ . Каждый раз, когда я сохраняю, это заставляет длинную строку разметки быть все на одной строке.

Если я установлю ‘vue/max-attributes-per-line’: 2 , он будет форматироваться так, с одним разрывом строки (что тоже совершенно неправильно).

Если я попытаюсь переформатировать его вручную, он просто вернется к описанному выше при сохранении.

Кроме того, он, кажется, переформатируется дважды, когда я нажимаю Ctrl+S: сначала он переформатируется, чтобы поместить все это в одну строку, а затем через полсекунды форматирование выше приводит к результатам. Есть идеи? Что вызывает эту странность-есть ли несколько работающих переформататоров? Как мне выяснить, что первый из них должен отключить его?

Настройки рабочей области VS Code:

Без изменения каких-либо настроек ESLint —fix действительно форматируется правильно-правильно разбивая все элементы шаблона my .vue на множество строк. Итак, есть какие-нибудь идеи, как я могу привести код VS в форму? Вышеприведенные настройки не помогли, но я в недоумении, как вообще узнать, что мешает. Есть идеи?

Чтобы подчеркнуть, когда я сохраняю в VS Code, длинный HTML-элемент свернется до одной строки, а затем через полсекунды разорвется на две строки, и все это из-за одной операции сохранения. Я ожидаю, что вместо этого он будет разбит на множество строк. Было бы хорошо, если бы это заняло несколько сохранений, но вместо этого первое сохранение показывает это поведение, а также каждое последующее сохранение.

Источник

Переносим Angular проект на ESLint, с Prettier, Husky и lint-staged

Привет, Хабр! Меня зовут Богдан, я работаю в ПИК Digital Front-End тимлидом. Большую часть проектов мы разрабатываем на Angular и недавно я решил пересмотреть наши стайл гайды, а также добавить новые инструменты для более удобной работы.

В качестве линтера я решил использовать ESLint, так как в скором времени на него планируют перевести Angular. И в этой статье я хочу поделиться инструкцией по переходу с TSLint на ESLint, а заодно рассказать, как запускать Prettier из ESLint, как добавить правила стайл гайда AirBnB, и как сделать линтинг удобным и незаметным с помощью настройки VS Code и Git хуков.

Prettier & ESLint

ESLint — это инструмент для статического анализа кода, правила в нём делятся на две группы:

• Форматирование — для приведения кода в один вид: длина строк, запятые, точки с запятой и тд.
• Качество кода — поиск проблемных шаблонов кода: ненужный код, ошибки.

Prettier — это инструмент автоматического форматирования кода.

Вопрос, который меня интересовал: зачем использовать Prettier, если ESLint тоже умеет форматировать код?

Ответ простой — Prettier форматирует код намного лучше: убирает всё форматирование и полностью переписывает код в едином стиле. Это позволяет разработчикам забыть о форматировании кода и не тратить время на обсуждение стиля кода на ревью. Например, у нас есть длинная строчка кода:

Если мы попробуем изменить форматирование через ESLint, он просто выдаст нам ошибку:

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

Если же мы сохраним или форматируем файл с Prettier, то строка примет вид:

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

Настройка ESLint

Суть линтинга с помощью ESLint заключается в парсерах, которые трансформируют код в AST (Abstract Syntax Tree) для дальнейшей программной обработки, и плагинах, которые содержат правила, например, рекомендуемые правила для линтинга TypeScript или правила код гайда AirBnB.

Установка

Для миграции Angular приложения на ESLint нам потребуются следующие зависимости:

• eslint — сам линтер,
• @angular-eslint/builder — Angular CLI Builder для запуска ESLint для приложений на Angular с помощью стандартной команды ng lint,
• @angular-eslint/eslint-plugin — плагин, содержащий правила для линтинга Angular,
• @angular-eslint/template-parser — парсер, который с помощью angular/compiler делает возможным написание правил для линтинга Angular шаблонов,
• @angular-eslint/eslint-plugin-template — плагин, который при использовании вместе с @angular-eslint/template-parser, запускает правила для линтинга Angular шаблонов,
• @typescript-eslint/parser — плагин для парсинга TypeScript кода,
• @typescript-eslint/eslint-plugin — плагин, который запускает правила для линтинга TypeScript.

Для их установки достаточно запустить команду:

На момент написания статьи в typescript-eslint и angular-eslint реализованы не все эквиваленты для правил из стандартной конфигурации Сodelyzer для TSLint, но большая часть уже есть. Отслеживать актуальное состояние переноса правил из TSLint в ESLint вы можете в монорепозиториях Angular ESLint и TypeScript ESLint.

Настройка конфига

Всё, что нам надо для линтинга Angular приложения, мы установили. Теперь перейдём к настройке ESLint. Давайте создадим файл .eslintrc.js и добавим рекомендованные настройки для Angular ESLint:

Конфиги можно описывать в разных форматах: JavaScript, JSON или YAML file. В JavaScript можно оставлять комментарии.

«plugin:@angular-eslint/recommended» содержит настройки сразу для 3 плагинов: «@typescript-eslint/eslint-plugin», «@angular-eslint/eslint-plugin» и «@angular-eslint/eslint-plugin-template». Прочитать, какие правила он задаёт, можно тут.

Обновление команды ng lint

Также в конфигурации angular.json нужно обновить команду ng lint на запуск @angular-eslint/builder:

Базовая настройка ESLint готова, теперь запустить ESLint можно стандартной командой ng lint.

Установка дополнительных плагинов

Чтобы установить плагин для ESLint, например, для линтинга unit-тестов в Angular, надо скачать и добавить в настройки плагин Jasmine:

И добавить в свойство «overrides» новый блок настроек для файлов с расширением *.spec.ts:

По аналогии вы можете добавить другие плагины для разных расширений файлов.

Добавляем правила стайл гайдов

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

• AirBnB: самый популярный и строгий из этих трёх, обязательные замыкающие запятые и точки с запятыми.
• Google: похож на AirBnB в плане форматирования, но менее строгий, обязательные комментарии JSDoc.
• StandartJS: запрещает использовать замыкающие запятые и точки с запятыми.

Выбирайте стайл гайд, который больше подходит вашей команде. Можете поочередно попробовать все стайл гайды на каком-нибудь большом проекте, посмотреть, какие ошибки выдаёт линтер и на основании этого сделать выбор.

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

В качестве примера, добавим в наш конфиг ESLint правила стайл гайда AirBnB. Для этого установим конфиг с правилами AirBnB для TypeScript и плагин с правилами для работы с синтаксисом import/export:

А также в свойстве «overrides» добавим правила стайл гайда AirBnB в блок с правилами для файлов с расширением «*.ts»:

Чтобы добавить другой стайл гайд, нужно установить набор правил для TypeScript, создать новый блок правил в «overrides» с правилами стайл гайда и указать необходимый для их работы парсер.

Кастомизация правил

Если вы хотите отключить или переопределить какие-то правила стайл гайда, то это можно сделать в свойстве «rules»:

Настройка Prettier

Чтобы добавить Prettier в нашу конфигурацию, нам надо установить сам Prettier, плагин с правилами Prettier, а также конфиг, который отключит все правила, которые могут конфликтовать с Prettier:

В «overrides» в блоке с правилами файлов с расширением *.ts в свойство «extends» в самый низ добавьте правила и настройки Prettier:

Конфигурация для Prettier всегда должна быть в самом низу списка, чтобы перезаписать все правила, которые могут конфликтовать с Prettier.

`prettier/@typescript-eslint` отключает правила `@typescript-eslint`, которые могут конфликтовать с Prettier, а `plugin:prettier/recommended` делает три вещи:

• включает eslint-plugin-prettier,
• выводит в консоль ошибки правил prettier/prettier как «error»,
• добавляет правила форматирования Prettier eslint-config-prettier.

Конфиг для Prettier:

Prettier умеет форматировать код без всяких настроек, но для соответствия стайл гайду AirBnB необходимо добавить некоторые настройки. Создайте файл .prettierrc.js в корне приложения:

Эти настройки будут использоваться как ESLint, так и Prettier, если вы будете использовать его для форматирования файлов в VS Code или с помощью команды:

Настройка VS Code

VS Code может подсвечивать и исправлять при сохранении ошибки найденные ESLint. Для этого надо скачать плагин ESLint для VS Code и создать файл внутри проекта с настройками для рабочей области .vscode/settings.json:

Здесь мы настраиваем ESLint, чтобы он подчёркивал и исправлял ошибки при сохранения файлов с расширениями .js, .ts и .html.

А чтобы форматировать документ комбинацией клавиш «shift+option+F» или «shift+alt+F» скачайте плагин Prettier для VS Code, и установите его как форматировщик по умолчанию.

Настройка Git хуков

Git хуки — это скрипты, которые Git вызывает при определённых событиях: commit, push, recieve.

С помощью них, мы можем запускать линтинг кода при создании коммита, чтобы в пул реквесты попадало меньше ошибок. Для более удобной работы с Git хуками установим Husky, а чтобы проверять только тот код, который добавлен в коммит (это полезно в больших проектах, где линтинг занимает много времени) lint-staged:

Добавим настройки для этих плагинов в package.json:

lint-staged передаёт в вызываемую команду массив изменённых файлов. Команда ng lint не умеет принимать массив файлов, и для её использования надо писать дополнительный скрипт-обработчик. А можно просто вызвать ESLint, как в этом примере. Такое решение можно использовать для прекоммитов, а ng lint запускать для линтинга всего проекта, например в CI пайплайне.

Выводы

В будущих версиях Angular ESLint с базовыми правилами будет из коробки. Сейчас процесс настройки ESLint требует некоторых дополнительных действий, в ESLint нет эквивалентов для некоторых правил из TSLint, и Angular ESLint ещё находится в alpha-версии. Поэтому переходить сейчас на ESLint или нет — решать вам.

Однако код гайды, дополнительные правила, Prettier, Husky и lint-staged вам придётся настраивать самостоятельно. Надеюсь эта статья помогла вам разобраться как все эти вещи работают вместе.

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

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

Пример реализации можно посмотреть на Github.

Если вы нашли ошибку в конфиге, или у вас есть дополнения — пишите!

Источник