Как настроить tslint vscode

Migrate from TSLint to ESLint

TSLint has been the recommended linter in the past but now TSLint is deprecated and ESLint is taking over its duties. This article will help you migrate from TSLint to ESLint.

ESLint: Installation

You need to install ESLint. ESLint doesn’t natively support TypeScript, so you will also need to install eslint-typescript-support:

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin 

or if you’re using yarn as your package manager:

yarn add eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin --dev 

The command above adds ESLint, adds a parser that makes ESLint understand TypeScript, and adds some TypeScript-specific rules.

Now, to make the actual migration simpler, run the tslint-to-eslint-config utility. This tool will take your TSLint configuration and create the «closest» ESLint configuration from it.

npx tslint-to-eslint-config 

This command downloads and executes the utility to perform the migration. For further options, check the utility’s usage guide.

There should now be a new .eslintrc.js file, a log file ( tslint-to-eslint-config.log ), and likely changes to other files, like .vscode/settings.json . Carefully review the changes, especially those made to existing files, and check the log file.

ESLint: Configure

The .eslintrc.js file is usually sufficient to get started but it’s likely that the parserOptions.project property is still set to your tsconfig.json file. That means that ESLint rules can use semantic information, for example, is this variable a string or a number-array? This configuration enables some powerful rules but means that ESLint takes much longer to compute. The default rules for extensions do not require semantic information and unless you have added rules that do, we recommend you remove the parserOptions.project property.

ESLint: Run

You are now ready to run ESLint, but before doing that, we recommend you disable TSLint. To do so, open the Extensions view and select Disable in the context menu of the TSLint extension.

It is time to lint! Use this command: eslint -c .eslintrc.js —ext .ts (notice the —ext .ts option which tells ESLint to look at TypeScript files). We recommend putting the command in the scripts section of your package.json -file, like so:

"lint": "eslint -c .eslintrc.js --ext .ts " 

To integrate ESLint with Visual Studio Code, do the following:

• Install the ESLint extension.
• Create a task via the Tasks: Configure Task command and select npm: lint.
• In the resulting tasks.json file, configure the problem matcher to be $eslint-stylish .

Hint: ESLint is sometimes «more correct» in how it does things and you may see warnings that you didn’t have before, for example calling out missing semicolons. Try the —fix option to let ESLint clean up things up for you.

TSLint: Removal

Congratulations. You should now have a working ESLint setup and it’s time to clean up.

The removal of TSLint depends on your project, but usually these are the steps:

Update .vscode/extensions.json to recommend the ESLint extension and not TSLint anymore:

"recommendations": [ "dbaeumer.vscode-eslint" ] 

Лошадь сдохла – слезь: переход с tslint на eslint

До недавнего времени во всех проектах фронта разработчики Dodo Pizza Engineering использовали tslint – полезный инструмент, который подсказывает, когда ты накосячил в коде допустил неточность, помогает поддерживать код в одном стиле и сам исправляет многие замечания. Но тут tslint взял и умер. Под катом я расскажу, почему так вышло, как перестать лить слёзы по умершему и перейти на инструмент eslint, а также покажу кое-что очень интимное.

На самом деле, началось всё довольно давно: последний релиз ядра tslint был аж в 2016 году. И это тот момент, когда пора начать говорить «последний», если кто-то до сих пор говорит «крайний», потому что тот релиз был действительно последним. 19 февраля 2019 года вышел официальный пост о прекращении разработки tslint. В нём компания-разработчик (кстати, это даже не Microsoft) настоятельно советует переходить всем на eslint, так как их усилия теперь будут направлены на улучшение поддержки TypeScript в этом линтере.

Один язык, один стек, одно комьюнити

Microsoft видит TypeScript, как основной язык веб-разработки, который должен вытеснить Java/ECMA Script. Очевидно, что такая амбициозная цель подразумевает единый стек инструментов для всей фронтовой разработки. Это должно существенно упростить миграцию большого комьюнити JS на TypeScript. Кроме гаранта доверия от Microsoft, у eslint архитектура лучше, чем у tslint. Например, можно подключать парсеры, а также выбор подключаемых правил больше.

Microsoft не был бы собой, если бы просто хотел. Что бы мы не говорили про качество их ПО, но инструменты разработки они делают отличные (и, кстати, устройства ввода). Вот и в этот раз они пришли не с пустыми руками, а написали план миграции. В соответствие с этим планом, разработка правил tslint уже прекращена 1 авгуcта 2019, а 1 ноября 2019 прекратится и разработка самого tslint. Хотя, если быть честными, разработка прекращена уже давно (см. выше про последний релиз).

Здесь читателю должно стать очевидно, что пора переходить на eslint, другого выбора нет. Чтобы подсластить пилюлю, стоит сказать что:

• в то время, как tslint ориентирован на TypeScript с бОльшим уклоном в правильное использование типов и проверку синтаксиса, eslint покрывает всё, что может быть во фронте, включая синтаксис React-компонентов;
• в eslint гораздо больше готовых правил;
• есть правила (и плагины), которые проверяют код на уровне блоков (дублирование кода, воспринимаемая сложность т.п.);
• есть плагины, которые проверяют вообще не код, а, например, регулярные выражения.

Добавляем eslint в проект

Про миграцию правил расскажу ниже. А пока настроим проект для работы с eslint.
Если у вас уже есть проект с tslint, то для начала удалите из него все пакеты, имеющие отношение к tslint: сам tslint, tslint-react, tslint-config-prettier и т.п.

Теперь добавьте в проект пакеты eslint (все ставим как devDependencies):

• сам eslint;
• @typescript-eslint/parser – движок парсинга TypeScript;
• @typescript-eslint/eslint-plugin – наборы правил для TypeScript

Минимальная настройка eslint

Создаём файл конфигурации .eslintrc.json. Eslint поддерживает много форматов файлов для своей конфигурации, но JSON кажется самым удобным. Вот как выглядит минимальный рабочий вариант:

< // Настройки проекта "env": < // Проект для браузера "browser": true, // Включаем возможности ES6 "es6": true, // Добавляем возможности ES2017 "es2017": true >, // Наборы правил "extends": [ // Базовый набор правил eslint "eslint:recommended", // Отключаем правила из базового набора "plugin:@typescript-eslint/eslint-recommended", // Базовые правила для TypeScript "plugin:@typescript-eslint/recommended", // Правила TS, требующие инфо о типах "plugin:@typescript-eslint/recommended-requiring-type-checking" ], // Движок парсинга "parser": "@typescript-eslint/parser", "parserOptions": < // Движку нужен проект TS для правил с типами "project": "tsconfig.json", "tsconfigRootDir": ".", >, // Плагин с наборами правил для TypeScript "plugins": ["@typescript-eslint"], "rules": <> >

Раздел env рассказывает eslint о параметрах вашего проекта. В моём примере – это проект для браузера (т.е. код будет работать в браузере). Пишите для Node.JS – ставьте node: true. Две последующие опции указывают на диалект проверяемого JS. Вообще, мы будем проверять код на TypeScript, но если в вашем проекте есть код и на JS, то не забудьте их подкрутить. Для себя мы решили, что ставим эти параметры в такое же значение, как и target в tsconfig.json.

В стандартных набораx правил eslint нет ничего спорного, вроде обязательной точки с запятой в конце выражений или пробелов/табов. Все правила однозначно полезные. Посмотреть, какие правила и с каким уровнем включаются, можно здесь.

Следующей же строкой вам необходимо отключить половину правил. Это необходимо, потому что они не работают с TypeScript и вместо нормальной работы будут сыпать кучу ошибок.

Затем следует подключить рекомендованные правила из TypeScript отдельным пакетиком. Здесь нужно иметь в виду, что общие синтаксические правила (типа запрета var) будут работать и так.

А вот для правил, использующих типы TS (например, @typescript-eslint/no-unnecessary-type-assertion), необходим движок TypeScript. А движку будет нужен файл tsconfig.json, путь до которого необходимо указать.

В tsconfig.json мы в Dodo Pizza Engineering обычно указываем exclude и выкидываем тесты, чтобы они не билдились вместе с проектом. Но для работы eslint необходимо указать и include. То есть все файлы, которые нужно линтить, должны быть включены в проект явно. Без этого eslint будет ругаться на каждый файл, который он найдет: «Файл не в проекте, я ничего делать не буду, буду сыпать кучу ошибок». Есть вариант без явного указания файлов проекта – установить параметр createDefaultProgram: true . Это, по сути, значит: «Всё, что найдешь – парси». Но делать так разработчики настоятельно не советуют из-за существенного падения производительности.

Если для обработки файлов TypeScript вы используете ForkTsCheckerWebpackPlugin, то замените в его параметрах (в webpack.config.ts) tslint: true на eslint: true .

Также стоит настроить запуск линтера из командной строки. До этого добавьте такое значение в раздел scripts в package.json :

"eslint": "eslint --cache --ext .js,.jsx,.ts,.tsx src", "eslint:dump": "eslint --print-config ./.eslintrc.json",

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

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

Настройка Visual Studio Code

После того, как вы проделали весь этот путь, уже можете запустить линтер из командной строки. Также он будет неявно запущен при сборке проекта. Но в Visual Studio Code замечаний от линтера мы не увидим. Да как так-то?!

Для студии есть плагин eslint (dbaeumer.vscode-eslint), его нужно поставить. После этого ничего всё равно не заработает, ничего не будет подчёркиваться и исправляться. Почему? Потому что у плагина есть конфиг, в котором написано, что работать нужно только в файлах JavaScript.

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

"eslint.validate": [ "javascript", "javascriptreact", "typescriptreact", "typescript", ],

После этого перезапустите студию, и всё наконец-то начнёт работать.

Теперь осталось настроить правила

Проект настроили. Теперь про правила, ведь в примере выше список правил был пуст.

Должен сказать, что tslint никак не мешал нам косячить в формально корректном коде. Например, забывать await. Eslint умеет находить подобные семантические ошибки и ругаться на них: сообщать, что возвращаемое значение – Promise, но для него, почему-то, не написан await. Сюда же относятся стилистические проблемы среднего уровня сложности: использование лямбды или function и т.п., что уже не умеет Prettier.

Что касается простых правил: положение скобок, tabs vs. spaces и т.п., есть мнение, что их следует отдать в Prettier или подобный пакет. Но в линтере их следует оставлять всё равно: это последний рубеж, который ещё способен остановить нерадивого разработчика упавшей сборкой проекта. Более того, этот рубеж можно автоматизировать: например, husky, позволяет запускать линтер автоматически на каждый commit.

Мы решили не мигрировать ни один из наборов правил tslint, что есть у нас. А создать свой набор с нуля.

Для eslint есть готовые наборы правил:

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

Обещанный интим: свой набор правил

Честно сказать, показать свой набор правил eslint – это как девушке показать сиськи: секретов больше нет. Я долго думал, стоит ли так делать. Но, посоветовавшись с коллегами-девушками, решил, что стоит.

Начну с плагинов, которые мы используем:

• react – проверки для кода react-компонентов. Базовый набор правил плюс наши. Из важного: топим за pure functional компоненты;
• react-hooks – правила от разработчиков react про использование хуков;
• promise – проверки на типичные ошибки при использовании Promise. Немного странно работает с кодом на TypeScript. Из важного: стараемся везде использовать Promise и не использовать колбеки и then/catch из-за лучшей читаемости кода;
• optimize-regex – забавный плагин, который даёт советы по улучшению регулярных выражений. Не слишком полезный, ибо regexp у нас немного. Но и владеют магией regexp далеко не все. Так что бывает полезно, а есть много не просит;
• sonarjs – огонь-плагин с проверками на сложность кода и типичные ошибки рефакторинга. Первое – забавная штука: плагин оценивает воспринимаемую сложность кода и даёт совет, когда код стоит упростить. Поиск ошибок рефакторинга часто позволяет также упростить код или, как минимум, улучшить читаемость;
• @typescript-eslint – правила eslint для проверки кода на TypeScript. И набор для отключения базовых правил, не совместимых с TS.

• Блог компании Dodo Engineering
• Программирование
• Совершенный код
• TypeScript

Линтер 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».

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

Настройка редактора

Настройте ваш редактор, чтобы улучшить опыт разработки и разблокировать новые функции Astro.

VS Code

VS Code — популярный редактор кода для веб-разработчиков, созданный Microsoft. Движок VS Code также обеспечивает работу популярных внутрибраузерных редакторов кода, таких как GitHub Codespaces и Gitpod.

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

• Подсветка синтаксиса для .astro файлов.
• Информация о типах TypeScript для .astro файлов.
• VS Code Intellisense для автодополнения кода, подсказок и многого другого.

Чтобы начать работу, установите расширение Astro VS Code сегодня.

�� Посмотрите, как настроить TypeScript в вашем проекте Astro.

Другие редакторы кода

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

• VS Code расширение в Open VSX Оффициальное — Оффициальное расширение Astro VS Code, доступное в реестре Open VSX для открытых платформ, таких как VSCodium
• Nova расширение Сообщество — Обеспечивает подсветку синтаксиса и автодополнение кода внутри Nova
• Vim плагин Сообщество — Обеспечивает подсветку синтаксиса, отступы, и поддержку сворачивания кода для Astro внутри Vim или Neovim
• Neovim LSP и TreeSitter плагины Сообщество — Обеспечивает подсветку синтаксиса, парсинг синтаксического дерева, и автодополнение кода для Astro внутри Neovim

Среды разработки JetBrains

Первоначальная поддержка Astro появилась в WebStorm 2023.1 (в настоящее время в раннем доступе). Вы можете установить официальный плагин через JetBrains Marketplace или выполнив поиск “Astro” во вкладке плагинов и воспользоваться такими функциями, как подсветка кода, автодополнение, и форматирование, с планами добавления еще более продвинутых функций в будущем. Он также доступен для всех других сред разработки JetBrains с поддержкой JavaScript.

Готовящаяся к выходу среда разработки Fleet от JetBrains также поддерживает языковые серверы, и поэтому, наши доступные в настоящий момент инструменты смогут работать там без каких-либо проблем.

Редакторы в браузере

В дополнение к локальным редакторам, Astro также работает с редакторами, размещенными в браузере, включая:

• StackBlitz и CodeSandbox — онлайн редакторы которые запускаются в вашем браузере, со встроенной поддержкой подсветки синтаксиса для .astro файлов. Установка или настройка не требуется!
• GitHub.dev — позволяет вам установить Astro VS Code расширение в качестве веб расширения, которое дает вам доступ только к некоторым функциям полного расширения. В настоящее время поддерживается только подсветка синтаксиса.
• Gitpod — полноценная среда разработки в облаке, которая может установить оффициальное расширение Astro VS Code от Open VSX.

Другие инструменты

ESLint

ESLint — популярный линтер для JavaScript и JSX. Для поддержки Astro может быть установлен поддерживаемый сообществом плагин.

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

Prettier

Prettier — популярный форматтер для JavaScript, HTML, CSS и многого другого. Чтобы добавить поддержку форматирования .astro файлов, используйте оффициальный плагин Astro Prettier.

Чтобы начать, сначала установите Prettier и плагин:

npm pnpm Yarn
Terminal window

npm install --save-dev prettier prettier-plugin-astro

Terminal window

pnpm install -D prettier prettier-plugin-astro

Terminal window

yarn add --dev prettier prettier-plugin-astro

Prettier автоматически обнаружит плагин и будет использовать его для обработки .astro файлов при запуске:

Terminal window

prettier --write .

Посмотрите README плагина Prettier для получения дополнительной информации о поддерживаемых опциях, о том, как настроить Prettier внутри VS Code, и многом другом.

Использование с pnpm

Из-за проблем с потоком внутри Prettier, плагин не будет автоматически обнаружен при использовании pnpm. Для того, чтобы найти плагин, при запуске Prettier необходимо добавить следующий параметр:

Terminal window

prettier --write . --plugin=prettier-plugin-astro

Дополнительные настройки также требуются при использованни Prettier внутри VS Code. Посмотрите README плагина для получения дополнительной информации.