- PVSM.RU - https://www.pvsm.ru -
До недавнего времени во всех проектах фронта разработчики Dodo Pizza Engineering использовали tslint – полезный инструмент, который подсказывает, когда ты накосячил в коде допустил неточность, помогает поддерживать код в одном стиле и сам исправляет многие замечания. Но тут tslint взял и умер. Под катом я расскажу, почему так вышло, как перестать лить слёзы по умершему и перейти на инструмент eslint, а также покажу кое-что очень интимное.
На самом деле, началось всё довольно давно: последний релиз ядра tslint был аж в 2016 году. И это тот момент, когда пора начать говорить «последний», если кто-то до сих пор говорит «крайний», потому что тот релиз был действительно последним. 19 февраля 2019 года вышел официальный пост [1] о прекращении разработки tslint. В нём компания-разработчик (кстати, это даже не Microsoft) настоятельно советует переходить всем на eslint, так как их усилия теперь будут направлены на улучшение поддержки TypeScript в этом линтере.
Microsoft видит TypeScript, как основной язык веб-разработки, который должен вытеснить Java/ECMA Script. Очевидно, что такая амбициозная цель подразумевает единый стек инструментов для всей фронтовой разработки. Это должно существенно упростить миграцию большого комьюнити JS на TypeScript. Кроме гаранта доверия от Microsoft, у eslint архитектура лучше, чем у tslint. Например, можно подключать парсеры, а также выбор подключаемых правил больше.
Microsoft не был бы собой, если бы просто хотел. Что бы мы не говорили про качество их ПО, но инструменты разработки они делают отличные (и, кстати, устройства ввода). Вот и в этот раз они пришли не с пустыми руками, а написали план миграции [2]. В соответствие с этим планом, разработка правил tslint уже прекращена 1 авгуcта 2019, а 1 ноября 2019 прекратится и разработка самого tslint. Хотя, если быть честными, разработка прекращена уже давно (см. выше про последний релиз).
Здесь читателю должно стать очевидно, что пора переходить на eslint, другого выбора нет. Чтобы подсластить пилюлю, стоит сказать что:
В общем, выглядит так, что переход на новый линтер, который являет собой мейнстримовый продукт, откроет нам целый мир ранее невиданных возможностей. Что ж, попробуем!
Про миграцию правил расскажу ниже. А пока настроим проект для работы с eslint.
Если у вас уже есть проект с tslint, то для начала удалите из него все пакеты, имеющие отношение к tslint: сам tslint, tslint-react, tslint-config-prettier и т.п.
Теперь добавьте в проект пакеты eslint (все ставим как devDependencies):
Создаём файл конфигурации .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 нет ничего спорного, вроде обязательной точки с запятой в конце выражений или пробелов/табов. Все правила однозначно полезные. Посмотреть, какие правила и с каким уровнем включаются, можно здесь [3].
Следующей же строкой вам необходимо отключить [4] половину правил. Это необходимо, потому что они не работают с TypeScript и вместо нормальной работы будут сыпать кучу ошибок.
Затем следует подключить рекомендованные правила из TypeScript отдельным пакетиком. Здесь нужно иметь в виду, что общие синтаксические правила [5] (типа запрета var) будут работать и так.
А вот для правил, использующих типы TS [6] (например, @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 замечаний от линтера мы не увидим. Да как так-то?!
Для студии есть плагин 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 [7], позволяет запускать линтер автоматически на каждый commit.
Мы решили не мигрировать [8] ни один из наборов правил tslint, что есть у нас. А создать свой набор с нуля.
Для eslint есть готовые наборы правил:
Ни один из готовых пакетов нам не понравился. Это может прозвучать странно, но для нас важно перейти на новый линтер, избежав стилистических войн. Если уж мы везде так пишем (табы, без точки с запятой, завершающие запятые обязательны), то пусть оно так и остаётся – главное, чтобы одинаково во всех проектах.
Честно сказать, показать свой набор правил eslint – это как девушке показать сиськи: секретов больше нет. Я долго думал, стоит ли так делать. Но, посоветовавшись с коллегами-девушками, решил, что стоит.
Начну с плагинов, которые мы используем:
Целиком наш файл правил лежит здесь [10]. Отмечу, что он не является догмой и обновляется по мере адаптации в проекты.
Автор: Борис
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/334882
Ссылки в тексте:
[1] официальный пост: https://medium.com/palantir/tslint-in-2019-1a144c2317a9
[2] план миграции: https://github.com/palantir/tslint/issues/4534
[3] здесь: https://github.com/eslint/eslint/blob/master/conf/eslint-recommended.js
[4] отключить: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/src/configs/eslint-recommended.ts
[5] общие синтаксические правила: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/src/configs/recommended.json
[6] использующих типы TS: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/src/configs/recommended-requiring-type-checking.json
[7] husky: https://github.com/typicode/husky
[8] не мигрировать: https://github.com/typescript-eslint/tslint-to-eslint-config
[9] воспринимаемую сложность: https://www.sonarsource.com/docs/CognitiveComplexity.pdf
[10] здесь: https://gist.github.com/BoresXP/e404f16a0e153eeb6ce15ce06848f36e
[11] Источник: https://habr.com/ru/post/473648/?utm_source=habrahabr&utm_medium=rss&utm_campaign=473648
Нажмите здесь для печати.