Настроить eslint для typescript

Setting ESLint on a React Typescript project (2021)

André Borba Netto Assis

Feb 18 · 7 min read

Introduction

After struggling a lot trying to install and understand ESLint on my React Typescript project, I decided to create a definitive guide to setting ESLint to a React Typescript project.

The main goal of this tutorial is to set up step-by-step and explain every line added or executed, instead of just giving you a bunch of files with a lot of configurations and expect that you will be able to understand what and how things are happening.

Prerequisites

Note: You need Node v ersion >= 10 installed. So, if you don’t have it, please go to NodeJS website, download and install it on your local machine. (https://nodejs.org/en/)

Step 1: Create a React Project with Typescript

The following command will create a project inside a folder my-app.

On terminal, run:

Step 2: Removing the pre-set ESLint configuration from React project

React comes with an eslint configuration pre-setted. Let’s remove this configuration so we can set a better one. To do this, remove the follow code from ‘package.json’ file

Step 3: Install ESLint package

Inside the project directory, open a terminal.

On terminal, run:

After run it, you will see that “ eslint” was added as a develop dependency on the ‘package.json’ file

PS: You can ignore if the version doesn’t match with the example shown above.

Step 4: Setup ESLint

Inside the project directory, open a terminal.

On terminal, run:

When running this command, you will need to answer some questions about the configuration:

How would you like to use ESLint?
Select: To check syntax, find problems, and enforce code style

What type of modules does your project use?
Select: JavaScript modules (import/export)

Which framework does your project use?
Select: React

Does your project use TypeScript?
Select: Yes

Where does your code run?
Select: Browser

How would you like to define a style for your project?
Select: Use a popular style guide

Which style guide do you want to follow?
Select: Airbnb: https://github.com/airbnb/javascript

What format do you want your config file to be in?
Select: JSON

After this, it will check the dependencies that need to be installed and then will ask:

Would you like to install them now with npm?
Select: Yes

Then, it will install all the packages needed. After the installation process, the ‘ devDependencies’ on “ package.json” file should look like this:

PS: You can ignore if the version doesn’t match with the example shown above.

Step 5: Running ESLint

Inside the project directory, open a terminal.

To run ESLint and see what errors it is pointing, just run:

To automatically fix some errors, you can use ‘ —fix’:

If you want to ignore warnings, you can use ‘ —quiet’

Step 5.1: Let’s Run!

If we just run the eslint to the whole files inside our ‘src’ directory, it will point 35 errors. WOW!

Running with auto-fix, it gets less scary, but we still have 22 errors to solve. OMG!

So, we ran through all those steps and just the ‘Hello World’ Project of ReactJS with Typescript gave us all these errors. And most of them make no sense, like extension file errors or even the use of React itself.

‘React’ was used before it was defined no-use-before-define

JSX not allowed in files with extension ‘.tsx’ react/jsx-filename-extension

The good news is that I’ve already been through this hell to solve these problems and now I will help you finish all the configuration so we can use ESLint properly. Let’s face each problem and what we need to do to solve it!

Solving remaining problems

Problem: “‘no-use-before-define”

Error sample: ‘React’ was used before it was defined

Solution

On ‘ eslintrc.json’, over “rules”, add the follow:

Problem: “‘react/jsx-filename-extension”

Error sample: JSX not allowed in files with extension ‘.tsx’

Solution

On ‘ eslintrc.json’, over “rules”, add the follow:

Problem: “import/no-unresolved”

Error sample: Unable to resolve path to module ‘./App’

Solution

• Inside the project directory, open a terminal and install eslint-import-resolver-typescript package

• On ‘ eslintrc.json’, Add a new property “ settings” to the json, as follow:

Problem: “import/extensions”

Error sample: Missing file extension ‘tsx’ for ‘./App’

Solution

On ‘ eslintrc.json’, over “rules”, add the follow:

Problem: “no-undef”

Error sample: ‘test’ is not defined

Solution

On ‘ eslintrc.json’, over “ extends”, add “ plugin:@typescript-eslint/recommended”:

Problem: “no-shadow”

Error sample: ‘Enum’ is already declared in the upper scope

Solution

On ‘ eslintrc.json’, over “rules”, add the follow:

Problem: Any error over files that are not ‘js’,’jsx’, ‘ts’, or ‘tsx’ extension files

Solution:

You can avoid ESLint to look over some files by adding it on the ‘ .eslintignore’ file.

• Create a ‘ .eslintignore’ file in the root of your project
• Add the follow text to it:

Extra:

Some nice rules to apply

Force all functions have explicit return type

On ‘ eslintrc.json’, over “ rules”, add:

Note: By enabling this rule, it will generate some ESLint errors that will be fixed by adding explicitly the return type of the functions on your code.

Max length of line code

On ‘ eslintrc.json’, over “ rules”, add:

React Hooks rules

On ‘ eslintrc.json’, over “ plugins”, add:

On ‘ eslintrc.json’, over “ rules”, add:

Some rules to ignore:

Prefer use of default export

On ‘ eslintrc.json’, over “ rules”, add:

Prop Types rules

On ‘ eslintrc.json’, over “ rules”, add:

Conclusion

So, with these configurations you will improve your code quality in your ReactJS with Typescript projects. Hope you enjoy! 🙂

VS Code: execute ESLint with auto fix in a file when save

As a plus, I will show you how to configure auto-fix on VS Code, but is an optional step, if you want to run ESLint with auto-fix every time you save your code.

• Create a ‘ .vscode’ folder on the root of the project
• Create a ‘ settings.json’ file inside .vscode/ folder and insert the follow code on it:

You can go to VS Code ‘Extensions’ section and install it manually:

Or launch VS Code Quick Open (Ctrl+P) AND Run the follow command:

• Allow ESLint extension usage on VS Code:

For the first time that you are using it, ESLint extension will be blocked. You should then allow it by:

1. Click on the status bar icon.

2. A popup will appears. Select ‘ Allow’ option.

Done! Now every file saved will fix the code with the ESLint rules that can be fixed automatically.

Источник

Лошадь сдохла – слезь: переход с 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 рассказывает 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, что позволяет увидеть настройки параметров правил.

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

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

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

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

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

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

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

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

Должен сказать, что 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.

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

Источник