Tslint что это
Перейти к содержимому

Tslint что это

  • автор:

Команда tslint: опции, ключи и примеры использования

Общие команды – Общие команды, присущие различным операционным системам.

tslint

  • Create tslint config:
  • Lint on a given set of files:
  • Fix lint issues:
  • Lint with the config file in the project root:

Изображение Выучи 10 хороших привычек для работы в UNIX от IBM

Примеры кода, демонстрирующие общие подходы в программировании или же решающие небольшие прикладные задачи. Языки программирования и библиотеки, позволяющие эффективно решать задачи разработки. Объектно-ориентированное программирование, функциональное программирование и прочие подходы и …

Фото Код

Трюки Bash

Полезные заметки по работе с командной строкой: bash и прочие *sh. Однострочники, скрипты, позволяющие решать большие и малые задачи администрирования и настройки Юникс систем. Zsh для современного MacOS, Bash для …

Фото Трюки Bash

Заметки о настройке различных IT-штуковин. Настройка, допиливание, полировка. Конфигурируем приложения и тюнингуем сервера. Полезные параметры и ключи запуска программ. Увеличиваем скорость, уменьшаем отклик, ускоряем работу и улучшаем результаты работы. Объясняем …

Фото Настройки

Терминал/Консоль

Команды и инструкции терминала (консоли) Linux, MacOS, Windows и прочих операционных систем. Трюки и особенности командных оболочек, скрипты для администрирования Unix. Программирование и скриптование Windows и Linux, тонкая настройка Macos. …

Фото Терминал/Консоль

Также может быть вам интересно:

  • Как получить дерево директорий на Bash одним однострочником
  • Python: Функции
  • Python: Встроенные типы данных (list, set, dict, etc)
  • Python: типы данных, переменные, логическое ветвление и циклы
  • Как сделать свою middleware в Django (с примерами)

Свежее на «Цифре»
MessageId или как дебажить систему с минимумом проблем
Программы, 50 дней назад
Проверочный список для выпуска промышленных приложений с иллюстрациями
Работа и управление, 91 день назад
В Google Pixel и Windows Snipping Tool есть возможность восстановления обрезанных изображений
Новости, 23.03.2023
Два подарка «под ёлочку» от Heroes of Might and Magic
Новости, 25.12.2022
Вышел Pulsar – редактор кода на основе Atom
Новости, 25.12.2022
Ленивый backup PostgreSQL
Программы, 17.12.2022
Google анонсировала OSV-Scanner: сканер уязвимостей в программных проектах
Новости, 16.12.2022

Фото Gitea запускает коммерческую версию, а недовольные – форк Forĝejo

Gitea запускает коммерческую версию, а недовольные – форк Forĝejo

На днях группа бывших разработчиков Gitea решили создать на базе хостинга кода Gitea свою версию проекта – «Forgejo». Причиной тому …

Фото Пользователи и их создание в Django - своя регистрация на сайте

Пользователи и их создание в Django — своя регистрация на сайте

Если вашим сайтом должны активно пользоваться несколько человек, то полезно их различать, а значит — надо уметь создавать пользователей, либо …

Фото Новый синтаксис старой команды with в Python 3.10

Новый синтаксис старой команды with в Python 3.10

Как же долго моё чувство прекрасного страдало… Но в Python 3.10 появился новый парсер синтаксических конструкций Python!

Фото Добавляем постраничную пагинацию на Django сайт

Добавляем постраничную пагинацию на Django сайт

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

Фото Новый оператор match-case в Python

Новый оператор match-case в Python

В новой версии Python (3.10) появится новый оператор. Новый оператор сопоставления по шаблону (match-case).

Фото Нет слов, одни. однострочники

Нет слов, одни. однострочники

На днях вышел пост со списком полезных однострочников для JavaScript программистов. Памятуя Perl-овую молодость, заглянул туда.

Фото Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

В Django вы можете передавать данные в шаблоны посредством контекстов. Контекст передаётся из контроллера (view в терминах Django), однако, если …

Фото Пример своей консольной команды в Django проекте

Пример своей консольной команды в Django проекте

Если вы работали с Django проектом, то, скорее всего, запускали команды из консоли (manage.py). В Django есть простой способ писать …

Фото Разграничение прав доступа на Django сайте

Разграничение прав доступа на Django сайте

Почти на любом веб-сайте необходимо разделять пользователей на группы и предоставлять им разные возможности. В Django есть довольно серьёзная система …

Как создать новый проект TypeScript

В этом руководстве вы узнаете, как создать простой проект TypeScript с нуля, без помощи стартового шаблона. Также мы поговорим о том, как работает компиляция в TypeScript и как использовать линтер в проекте TypeScript.

Требования

Для выполнения этого мануала вам понадобится:

  • Последняя версия Node, установленная на вашем компьютере. Инструкции по установке зависят от вашего дистрибутива: mac OS, Debian, CentOS, Ubuntu.
  • Умение работать с npm. Пакетный менеджер npm поставляется с Node. Чтобы узнать больше о работе с npm, ознакомьтесь с руководством Управление модулями Node.js с помощью npm и package.json.

1: Инициализация проекта TypeScript

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

Перейдите в него:

Сюда вы можете установить TypeScript:

npm i typescript —save-dev

Важно включить флаг –save-dev, поскольку он сохраняет TypeScript как зависимость разработки. Это означает, что TypeScript абсолютно необходим для разработки проекта, но не для среды производства.

Установив TypeScript, вы можете инициализировать свой проект, используя следующую команду:

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

Мы используем здесь команду tsc, потому что это встроенный компилятор TypeScript. Когда вы пишете код на TypeScript, команда tsc преобразует или компилирует код в JavaScript.

Флаг –init в приведенной выше команде инициализирует проект путем создания файла tsconfig.json в каталоге проекта typescript-project. Этот файл позволяет вам дополнительно настраивать взаимодействие TypeScript и компилятора tsc. Вы можете удалять, добавлять и изменять конфигурации в этом файле в соответствии с вашими потребностями.

Откройте файл tsconfig.json в любом редакторе кода, и вы увидите следующие конфигурации по умолчанию:

Многие конфигурации по умолчанию будут закомментированы. Приведенные выше параметры определяют версию JavaScript, в которую будет скомпилирован TypeScript, и ожидаемую систему модулей для скомпилированной программы. Параметр strict со значением true включает широкий диапазон правил проверки типов. Это означает, что ваша программа TypeScript будет содержать меньше ошибок.

Вы можете внести свои правки в конфигурацию TypeScript. Откройте файл tsconfig.json и добавьте следующие пары ключ-значение:

 < "compilerOptions": < "target": "es5", "module": "commonjs", "strict": true, "outDir": "dist", "sourceMap": true > >

Если присвоить outDir значение dist, при компиляции будет создана папка по имени dist. При запуске команды npx tsc для компиляции файла TypeScript скомпилированный файл JavaScript будет помещен в файл dist.

Также при компиляции файла TypeScript будет создан sourcemap – это файл, который сопоставляет новый скомпилированный файл JavaScript с исходным файлом TypeScript. Если в вашем коде есть ошибки или вам необходимо внести изменения, лучше отлаживать исходный код, а не скомпилированный. Вот почему полезны файлы sourcemap. Установив для параметра sourceMap значения true, вы сможете быстро устранять ошибки в исходном файле TypeScript.

Переходим к написанию кода приложения TypeScript и его компиляции.

2: Компиляция проекта TypeScript

Прежде чем приступить к написанию кода своего проекта TypeScript, создайте в проекте typescript папку src, а внутри src создайте файл index.ts.

Затем откройте index.ts в редакторе кода и вставьте в этот файл следующий код TypeScript:

const world = 'world'; export function hello(word: string = world): string < return `Hello $! `; >

Имея этот код, index.ts готов к компиляции:

npx tsc index.ts

Вы заметите, что в папку dist были добавлены скомпилированный JavaScript-файл index.js и файл sourcemap index.js.map.

Откройте index.js, и вы увидите следующий скомпилированный код JavaScript:

"use strict"; Object.defineProperty(exports, "__esModule", < value: true >); var world = 'world'; function hello(word) < if (word === void 0) < word = world; >return "Hello " + world + "! "; > exports.hello = hello; //# sourceMappingURL=index.js.map

Запускать компилятор TypeScript каждый раз, когда вы вносите изменения, довольно утомительно. Чтобы избежать этого, вы можете перевести компилятор в режим наблюдения. В этом режиме файл TypeScript будет перекомпилироваться каждый раз после внесения изменений.

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

Итак, вы знаете, как работает компилятор TypeScript, и можете компилировать файлы. Пора вывести свой проект TypeScript на новый уровень, внедрив в свой рабочий процесс линтер.

3: Настройка TSLint для проекта TypeScript

Использование линтера при написании кода поможет вам быстро выявить несоответствия, синтаксические ошибки и упущения. Стандартный линтер TypeScript называется TSLint (он считается устаревшим и вместо него рекомендуется использовать ESLint).

Чтобы установить TSLint, выполните следующую команду:

npm i tslint —save-dev

TSLint установлен. Чтобы настроить его для работы с вашим проектом, выполните следующую команду для инициализации:

npx tslint —init

Команда инициализации TSLint создаст файл tslint.json, в нем хранятся все конфигурации TSLint в tslint.json. Откройте tslint.json в редакторе кода. Вы увидите следующие стандартные конфигурации:

< "defaultSeverity": "error", "extends": [ "tslint:recommended" ], "jsRules": <>, "rules": <>, "rulesDirectory": [] >

Линтеры подчеркивают ошибки в коде. Чтобы включить это поведение в редакторе кода, необходимо установить расширение TSLint.

Примечание: Если после установки расширение не будет работать, попробуйте установить в редакторе расширение ESLint.

Вернитесь в файл index.ts в редакторе кода. Вы заметите, что в двух местах появилось подчеркивание: одинарные кавычки должны быть двойными, а сам файл должен заканчиваться новой строкой. Оба этих замечания не являются ошибками как таковыми, это стилистические рекомендации, которые отслеживает TSLint. Вы можете изменить это поведение в файле tslint.json. Это делается в рамках пары ключ-значение rules:

< "defaultSeverity": "error", "extends": [ "tslint:recommended" ], "jsRules": <>, "rules": <>, "rulesDirectory": [] >

Допустим, вы не хотите включать новую строку в конец каждого файла. Вы можете отключить эту рекомендацию с помощью правила eofline. Установите для eofline значение false, после чего подчеркивание пропадет:

"rules": < "eofline": false >,

Вам не нужно вручную устанавливать каждое правило, которое вы хотите добавить. TSLint поддерживает ряд широко известных конфигураций, которые вы можете просто интегрировать в свой файл. Руководство по написанию кода от Airbnb – это надежный набор настроек, которым доверяют многие разработчики.

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

npm install tslint-config-airbnb

Установив его, нужно убедиться, что конфигурации в tslint.json поддерживают его. Ключ extends должен указывать на недавно установленный tslint-config-airbnb:

 < "defaultSeverity": "error", "extends": "tslint-config-airbnb", "jsRules": <>, "rules": < "eofline": false >, "rulesDirectory": [] >

После интеграции руководства по стилю Airbnb в tslint.json линтер больше не будет выдавать сообщение об ошибке при использовании одинарных кавычек. У Google также есть широко используемое руководство по написанию кода TypeScript под названием gts, в котором есть еще более полезные функции.

4: Использование gts

Установив линтер, вы можете использовать сторонние инструменты, чтобы избежать необходимости настраивать линтинг и конфигурацию в файле tsconfig.json. Google TypeScript Style (сокращенно gts) – один из таких инструментов. Он представляет собой руководство по написанию кода, линтер и автоматический корректор кода – все в одном. Инструмент gts поможет вам быстро запустить новый проект TypeScript и избежать сбоев в его работе. Также gts предлагает довольно необычную конфигурацию по умолчанию, которую не придется долго настраивать.

Чтобы протестировать gts, давайте попробуем создать новую папку проекта. Когда папка проекта будет готова, инициализируйте gts с помощью следующей команды:

Приведенная выше команда сгенерирует все, что вам нужно для начала работы с TypeScript, включая файл tsconfig.json и настройку линтинга. Также она создаст файл package.json, если его еще нет.

Кроме того, команда npx gts init добавит в файл package.json полезные сценарии npm. Например, теперь для компиляции вашего проекта TypeScript вы можете запустить команду npm run compile. Чтобы проверить наличие ошибок с помощью линтера, вы можете запустить npm run check.

Примечание: Изучите документацию по gts, чтобы узнать, как интегрировать gts с линтером ESLint.

Чтобы использовать TSLint в проекте TypeScript, вам все равно необходимо установить TSLint и запустить npx tslint –init, чтобы создать конфигурационный файл tslint.json. В предыдущем разделе мы расширили TSLint, интегрировав руководство Airbnb. Для gts нужно сделать то же самое:

 < "defaultSeverity": "error", "extends": [ "./node_modules/gts/tslint.json" ], "jsRules": <>, "rules": <>, "rulesDirectory": [] >

Теперь TSLint будет следовать правилам линтинга, установленным gts.

Итак, gts установлен и интегрирован в ваш проект TypeScript. Используя gts, вы сможете быстро создавать новые проекты TypeScript с необходимыми конфигурациями.

Заключение

В этом руководстве вы создали простой проект TypeScript с пользовательскими конфигурациями. Вы также интегрировали Google TypeScript Style в свой проект TypeScript. Инструмент gts поможет вам быстро приступить к работе с новым проектом TypeScript. Благодаря gts вам не нужно вручную настраивать конфигурацию или интегрировать линтер в рабочий процесс.

Лошадь сдохла – слезь: переход с 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

Программируем лучше с ESLint, Prettier и TypeScript

Рассказ о том, как правильно управлять инструментами ESLint и Prettier, которые позволяют писать более читабельный и продуктивный код.

Олег Бидзан
Технический директор Simtech Development

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

Как все начиналось

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

Во-первых, бесконечные споры о том, как писать и форматировать код. Это действительно надоевшая всем тема, по крайней мере, для меня. Личным предпочтениям тут не место. Есть более важные вещи, на которые стоит обратить внимание.

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

В-третьих, мощь этих инструментов. Они помогают заниматься действительно важными вещами вместо того, чтобы отвлекаться от процесса, если, например, код отформатирован неправильно, на что чаще всего обращают внимание на code review.

И, в конце концов, это всё про бизнес, неважно насколько нам нравится то, что мы делаем. Это просто трата времени. Вы можете потратить его эффективнее.

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

Инфо Скорее всего поддержки TSLint в Angular не будет в ближайшее время т.к. TypeScript решили внедрить ESLint вместо TSLint. Команда Angular уже работает нам переездом с TSLint на ESLint. См. issue.

Что такое ESLint, и как это может помочь нам?

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

Что я должен сделать, чтобы начать использовать ESLint?

Я рассчитываю, что у вас уже установлены node и npm, и вы знакомы с ними.

Создание рабочей папки

Перейдите в папку, где находится ваш JavaScript или TypeScript проект, или, как я, создайте тестовую папку lint-examples, где мы можем работать по ходу статьи. В операционных системах на основе Linux наберите mkdir lint-examples в командной строке и затем перейдите в созданную папку с помощью команды cd lint-examples .

Вводный курс по TypeScript

Установка ESLint

Теперь давайте создадим package.json, чтобы мы могли установить ESLint. Выполнение команды npm init создаст package.json, который необходим для установки eslint в вашу папку.

Добавьте eslint в ваши npm скрипты

< "name": "eslint-examples", "version": "0.0.0", "description": "", "main": "index.js", "scripts": < "eslint": "eslint" >, "devDependencies": < "eslint": "7.1.0" >> 

Подсказка «eslint»: «eslint» в скриптах — это сокращение для node_modules/.bin/eslint.

Создайте test.js

Давайте создадим простой JavaScript-файл в папке lint-example, куда мы установили ESLint. Не переживайте о плохом форматировании примера. Нам нужно это для старта.

var foo = 1 console.log(foo) var bar bar = 1 function test( ) < console.log(baz) >var baz = 123 

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

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

Если вы использовали const или let в примере выше, ESLint генерирует ошибку, потому что, как уже говорилось, ES5 выбран по умолчанию.

Подсказка Используя — вы можете передать аргументы через npm-скрипты в командную строку eslint.

npm run eslint — ./test.js

Становится интереснее!

В зависимости от того насколько современен ваш проект, вы должны выставить правильные опции. В наших примерах мы предполагаем, что вы хотите использовать современный ES6 синтаксис.

Давайте создадим наш первый .eslintrc.

Существует несколько способов передать конфигурации в ESLint. Я предпочитаю .eslintrc. По ссылке вы найдете другие способы.

Инфо env обязателен для глобальных переменных. Когда мы настраиваем параметры env , устанавливая es6 в true , ESLint включит глобальность для всех новых типов, таких как Set . Это так же включит ES6 синтаксис, например, let и const . Смотрите установка опций парсера.

Сейчас мы должны добавить несколько правил в наш .eslintrc

Можем ли мы просто определить правила? Да, потому что установили ESLint, который содержит множество правил из коробки. Для особых правил, таких как TypeScript или новых функций, которые не поддерживаются ESLint, мы должны установить модули eslint-config-xxx или eslint-plugin-xxx . Но мы можем вернуться к этому позже. Вы можете посмотреть правила по ссылке.

< "env": < "es6": true >, "rules": < "no-var": "error", "semi": "error", "indent": "error", "no-multi-spaces": "error", "space-in-parens": "error", "no-multiple-empty-lines": "error", "prefer-const": "error", "no-use-before-define": "error" >> 

Если вы запустите npm run eslint , то должны получить результат в точности как ниже:

error 'foo' is never reassigned. Use 'const' instead prefer-const error Missing semicolon semi error Expected indentation of 0 spaces but found 4 indent error 'bar' is never reassigned. Use 'const' instead prefer-const error Multiple spaces found before ')' no-multi-spaces error There should be no space after this paren space-in-parens error There should be no space before this paren space-in-parens error More than 2 blank lines not allowed no-multiple-empty-lines error 'baz' was used before it was defined no-use-before-define error 'baz' is never reassigned. Use 'const' instead prefer-const 26 problems (26 errors, 0 warnings) 20 errors and 0 warnings potentially fixable with the `--fix` option. 

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

Возможно, вы увидели в выводе результата ESLint, что 20 проблем из 26 могут быть решены автоматически. Мы вернемся к этому в следующем разделе.

ESLint и форматирование кода?

ESLint может автоматически форматировать ваш код до определенной стадии. Как вы возможно видели в выводе лога, дополнительный флаг —fix может быть использован для форматирования написанного кода, основываясь на правилах eslint. Например, пропущенная точка с запятой может быть добавлена автоматически, а несколько пустых строк подряд будут удалены. Это так же работает для других правил.

Давайте исправим код, выполнив npm run eslint — ./ —fix

var foo = 1; console.log(foo); var bar; var = 1; function test( ) < console.log(baz); >var baz = 123; 
1:1 error Unexpected var, use let or const instead no-var 3:1 error Unexpected var, use let or const instead no-var 11:1 error Unexpected var, use let or const instead no-var 3 problems (3 errors, 0 warnings) 

Вы видите, что ESLint исправляет не все правила. Оставшиеся три ошибки необходимо поправить вручную, однако остальные ошибки из отчета ESLint (такие как «Пропущенная точка с запятой», «Неправильные отступы», «Множественные пробелы») были исправлены автоматически.

Обратите внимание Причина, по которой var не может быть исправлена, — в каких-то действиях с контекстом браузера. Вы можете почитать подробнее по ссылке.

В документации ESLint вы можете найти, какие правила можно активировать с помощью иконки «check mark». Код, который может быть отформатирован автоматически, подсвечивается с помощью иконки гаечного ключа.

  • Правила можно найти по ссылке.
  • Существует примерно 300 правил, и их число постоянно растет.
  • Примерно 100 из этих правил делают автоформатирование.

Всё это становится мощнее, если код форматируется вашей IDE при изменении (сохранении) файла, или если любой инструмент автоматизации, например travis-ci, может взять на себя эту задачу, когда что-то отправляется в Git.

Если ESLint может форматировать ваш код, что тогда делает Prettier?

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

Что надо сделать, чтобы начать использовать Prettier?

Не так много. Просто добавьте в ваши npm-скрипты «prettier»: «prettier» и запустите npm install prettier .

Как мы помним, этот код был отформатирован ESLint, и он не очень хорошо оформлен.

// test.js const foo = 1; console.log(foo); let bar; bar = 1; function test( ) < console.log(baz); >const baz = 123; 

После выполнения npm run prettier — —write ./test.js код выглядит опрятнее.

const foo = 1; console.log(foo); let bar; bar = 1; function test() < console.log(baz); >const baz = 123; 

Так намного лучше. Чем больше кода, тем лучше результат.

Могу ли я настраивать Prettier?

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

Это мои настройки, которые описаны в файле .prettierrc. Полный список опций вы можете найти по ссылке. Давайте создадим .prettierrc-файл с такими опциями.

Запускать ли ESLint и Prettier одновременно?

Не рекомендуется запускать ESLint и Prettier по отдельности, чтобы применить правила написания кода и форматирования. Более того, ESLint и Prettier будут мешать друг другу т.к. у них есть пересекающиеся правила, и это может привести к непредсказуемым последствиям. В следующем разделе мы рассмотрим эту проблему и решим ее. Если кратко, то вы просто запускаете eslint в командной строке, а prettier будет уже включаться туда.

Как всё это начиналось!

Как я писал в начале статьи, я никогда не использовал ESLint и Prettier прежде. Следовательно, я не знал, как эти утилиты работают. Как любой разработчик, я копировал наилучший кусок кода из глубин интернета в мой .eslintrc-файл без понимания, что это даст. Главной целью было, чтобы это работало.

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

Если коротко, то там настройки и плагины для ESLint, предоставленные сообществом открытого исходного кода. Мы не должны делать их сами. Главное понимать, как это работает под капотом.

< "plugins": [ "@typescript-eslint", "prettier", "unicorn" , "import" ], "extends": [ "airbnb-typescript/base", "plugin:@typescript-eslint/recommended", "plugin:unicorn/recommended", "plugin:prettier/recommended", "prettier", "prettier/@typescript-eslint" ], "parserOptions": < "ecmaVersion": 2020, "sourceType": "module" >, "env": < "es6": true, "browser": true, "node": true >, "rules": < "no-debugger": "off", "no-console": 0 >> 

Заметка Возможно, вы заметили prettier в плагинах, и вы все еще помните, что я писал выше: «Должны ли мы одновременно запускать ESLint и Prettier для форматирования кода?» Ответ нет, потому что eslint-plulgin-prettier и eslint-config-prettier сделают всю работу за вас.

Что означают эти настройки и опции?

После того, как я заставил систему работать, то задался вопросом, а что это всё значит. Это буквально выбило меня из колеи. Если вы запустите ESLint в вашей консоли с этими опциями, то получите сообщение об ошибке, что конфига (расширения) и плагины не установлены. Но откуда мы можем знать, что устанавливать? Каждый знаком с процессом, вы находите кусок кода на StackOverflow или в каком-то репозитории и потом не знаете, как правильно запустить его.

Вы должны помнить, что все модули внутри extends и plugins могут быть установлены. Но сначала вы должны узнать, как интерпретировать соглашение об именах в свойствах, чтобы иметь возможность устанавливать их через npm.

Что такое опции «плагина»?

Плагины содержат правила написанные с использованием парсера. Это могут быть правила на рассмотрении из TC39, которые еще не поддерживаются ESLint, или специальные рекомендации по написанию кода, которые не представлены в ESLint, например, unicorn/better-regex, import/no-self-import.

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

Давайте узнаем, как интерпретировать соглашение об именах плагинов

Если имя плагина начинается не с eslint-plugin- или @ или ./ , вы просто должны добавить префикс eslint-plugin- .

plugins: [ "prettier", // npm module "eslint-plugin-prettier" "unicorn" // npm module "eslint-plugin-unicorn" ] 

Еще пример, работает так же:

plugins: [ "eslint-plugin-prettier", // the same as "prettier" "eslint-plugin-unicorn" // the same as "unicorn" ] 

Становится немного сложнее, когда вы сталкиваетесь с именами плагинов, которые начинаются с @ (пространство имен). Как видно из приведенного ниже примера, использование / ограничено одним уровнем. Вы должны учитывать, что @mylint и @mylint/foo находятся в одном и том же пространстве имен, но это два разных плагина (npm-модуля).

plugins: [ "@typescript-eslint", // npm module "@typescript-eslint/eslint-plugin" "@mylint", // npm module "@mylint/eslint-plugin" "@mylint/foo", // npm module "@mylint/eslint-plugin-foo" "./path/to/plugin.js // Error: cannot includes file paths ] 

Код примера ниже такой же, как и сверху.

plugins: [ "@typescript-eslint/eslint-plugin", // the same as "@typescript-eslint" "@mylint/eslint-plugin", // the same as "@mylint" "@mylint/eslint-plugin-foo" // the same as "@mylint/foo" ] 

На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

Используйте сокращенную форму (из первого примера) вместо длинной формы (из второго примера). Главное, чтобы вы понимали, как ESLint это конвертирует внутри.

Теперь мы знаем, как работает соглашение об именах для плагинов. Установите следующие плагины ESLint через npm.

npm i eslint-plugin-prettier eslint-plugin-unicorn

В документации ESLint вы можете найти дополнительную информацию о соглашении об именах.

Для тестирования ваш .eslintrc должен выглядеть следующим образом:

Prettier: ESLint плагин для форматирования кода.

Unicorn: дополнительные правила, которые не поддерживаются ESLint.

Теперь, если вы запустите npm run eslint в командной строке, вы не получите сообщение об ошибке, но также не получите и вывод ESLint. Это потому, что мы должны зарегистрировать модуль плагина в свойстве extends нашего .eslintrc-файла или применить его, активировав в разделе rules .

Давайте выясним, как интерпретировать соглашение об именах в расширениях

Прежде всего, если вы считаете, что соглашение об именах в разделе extends такое же, как и у плагинов, я должен вас разочаровать. Есть отличия. Должен честно признать, что мне потребовалось много времени, чтобы заметить разницу. Это было отчасти потому, что ESLint — сложная и обширная тема, по крайней мере, для меня.

Пока вы используете только простое имя (например, foo ) без префикса пространства имен ( @ ) или с (./to/my/config.js), принцип соглашений об именах в extends такой же, как и с параметром plugins . Таким образом, foo становится eslint-config-foo

extends: [ "airbnb-base", // npm module "eslint-config-airbnb-base" "prettier" // npm module "eslint-config-prettier" ] 
extends: [ "eslint-config-airbnb-base", // shortform is "airbnb-base" "eslint-config-prettier" // shortform is "prettier" ] 

Итак, мы подошли к тому, что существуют различия в соглашении об именах между plugins и extends . Это тот случай, когда вы используете пространства имен ( @ ) в разделе extends . Следующая конфигурация ESLint @mylint все та же, она указывает на модуль npm @mylint/eslint-config , но @mylint/foo может привести к ошибке при использовании в extends из-за отсутствия префикса eslint-config- в @mylint/eslint-config-foo .

extends: [ "@bar", // npm module "@bar/eslint-config" "@bar/eslint-config-foo", // npm module "@bar/eslint-config-foo" "@bar/my-config" // npm module "@bar/eslint-config/my-config" ] 

Как я писал в введении к предыдущему разделу, следующий @mylint/my-config немного особенный, поскольку он содержит модуль npm, но в то же время он указывает изнутри ESLint на набор правил ( my-config ). Мы скоро это выясним. Вот официальная документация по соглашению об именах extends .

Давайте установим остальные модули npm для нашего примера.

npm i eslint-config-airbnb-base eslint-config-prettier

Примечание: возможно, вы заметили, что сначала мы установили eslint-plugin-prettier , а теперь установили eslint-config-prettier . Это разные модули, но работают только вместе. Мы обсудим это позже.

Что конкретно делает extends в .eslintrc?

Конфиг предоставляет предварительно настроенные правила. Эти правила могут состоять из правил ESLint, правил сторонних плагинов или других конфигураций, таких как синтаксический анализатор (babel, esprima, и т.д.), параметров (sourceType, и т.д.), окружений (ES6, и т.д.) и других.

Звучит неплохо? Да, потому что мы не должны делать всё сами. Продвинутые разработчики и команды уже потратили на это много времени. Всё, что нужно сделать, это активировать правила, указав конфиг или набор правил плагинов.

Где я могу найти эти наборы правил?

Есть разные способы их найти.

Во-первых, вы должны посмотреть на README.md соответствующего репозитория и прочитать именно то, что написано. Обычно, эти наборы правил называются «рекомендованными» и должны быть активированы для plugins . Для extends это не всегда необходимо.

Во-вторых, знание того, какой набор правил использовать даже без чтения README.md — вот, что я считаю гораздо более эффективным. Особенно, если файл README.md является неполным или неправильным.

По сути, вы можете сказать, что «плагины» указывают на один файл, где конфигурации (наборы правил), содержащиеся в объекте и «расширениях», указывают на наборы правил, которые находятся в разных файлах.

eslint-config-airbnb-base

eslint-config-airbnb-base (repository) | -- index.js | -- legacy.js | -- whitespace.js 

Вы можете активировать все конфигурации одновременно, но будьте осторожны. Вы должны заранее знать, что они делают. Обычно я предварительно изучаю связанные README.md файлы или непосредственно соответствующие наборы правил конфигурации. Довольно легко, когда вы поймете, как их активировать, верно?

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

"extends": [ "airbnb-base", // index.js "airbnb-base/whitespace" // whitespace.js ] 

Держите в уме Порядок играет роль, потому что набор правил будет расширять или перезаписывать предыдущие. Так что не переусердствуйте с конфигами и плагинами. Смотрите хорошее объяснение на StackOverflow.

eslint-plugin-prettier

Теперь мы подошли к захватывающей части статьи. Как мы можем использовать Prettier напрямую в ESLint, не запуская его в качестве отдельной службы в нашей командной строке или IDE?

Мы начнём с активации eslint-plugin-prettier в разделе extends, а затем связанного с ним config eslint-config-prettier , который отвечает за деактивацию некоторых наборов правил ESLint, которые могут конфликтовать с Prettier.

eslint-plugin-mylint (repository) | -- eslint-plugin-prettier.js (because this is specified as entrypoint in package.json) 
module.exports = < configs: < recommended: < extends: ['prettier'], plugins: ['prettier'], rules: < 'prettier/prettier': 'error' >> > . . . 

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

"extends": [ "plugin:prettier/recommended" ] 

Подсказка Плагины должны быть зарегистрированы в plugins и активированы в extends с использованием :plugin префикс.

eslint-config-prettier

eslint-config-prettier (repository) | -- index.js | -- @typescript-eslint.js | -- babel.js | -- flowtype.js | -- react.js | -- standard.js | -- unicorn.js | -- vue.js 

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

"extends": [ "prettier", // index.js "prettier/unicorn", // unicorn.js "prettier/@typescript-eslint" // @typescript-eslint.js ] 

Примечание Отдельно «prettier» в extends требуется для отключения некоторых правил ядра ESLint. В остальных случаях «prettier.» необходимы для отключения правил в unicorn и @typescript-eslint .

Мой личный конфиг ESLint выглядит как приведенный выше пример. Я использую TypeScript и плагин Unicorn. Не хочу, чтобы они конфликтовали с ESLint. Поэтому некоторые правила TypeScript и Unicorn отключены через Prettier.

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

Проверяем себя и других: чек-лист для код-ревью

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

.eslintrc

"rules": < "unicorn/prevent-abbreviations": "off" > 

Итак, вернёемся к нашему тестовому примеру. Теперь наш .eslintrc-файл должен выглядеть следующим образом:

< "plugins": [ "prettier", "unicorn" ], "extends": [ "airbnb-base", "plugin:unicorn/recommended", "plugin:prettier/recommended", "prettier", "prettier/unicorn" ], "env": < "es6": true, "browser": true >, rules: < "unicorn/prevent-abbreviations": "off" >> 

Стратегия При переходе на ESLint может случиться так, что в выводе ESLint отображается много ошибок. Правка по ходу дела может занять много времени или даже привести к побочным эффектам. Если вы хотите переходить постепенно, рекомендуется оставить правила в режиме warning , а не error .

Если вы теперь запустите наш пример через ESLint, используя npm run eslint — —fix , Prettier будет выполняться через ESLint, так что вам потребуется только одна команда для запуска обоих инструментов.

Как мы можем интегрировать это в IDE?

Все современные IDE (IntelliJ и VS Code) поддерживают ESLint. Важно отметить, что в некоторых случаях вы должны передавать параметр —fix в качестве аргумента в настройках IDE, чтобы всё работало автоматически.

Почему существуют разные типы парсеров “ESLint”?

ESLint поддерживает только новый синтаксис JavaScript, который находится на финальной стадии в TC39. Возможно, не многие знают это, но компилятор Babel поддерживает функции, которые ещё не находятся на финальной стадии. Хорошо известная функция – decorator . От функции, на которой был основан Angular, отказались. Новая же функция имеет другой синтаксис и семантику. Предыдущая функция находится на второй стадии, а новая — на раннем этапе.

В этом случае ESLint вам не поможет. Либо вам нужно найти подходящий плагин для него, либо вы пишете свой собственный плагин eslint, который использует, например, анализатор babel вместо анализатора espree, который является анализатором по умолчанию в ESLint.

Как насчёт Angular и ESLint?

Команда Angular придерживается мнения, что нам следует подождать с применением ESLint. Это допустимо, потому что они хотят сделать переход как можно более плавным, но если вы всё же хотите попробовать, вот несколько советов.

Производительность и ESLint?

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

Prettier существует только для Javascript?

Prettier официально поддерживает несколько других языков. К ним относятся PHP, Ruby, Swift и так далее. Кроме того, существуют плагины сообщества для таких языков как Java, Kotlin, Svelte и многих других.

Как насчет ESLint v7?

Все примеры в нашей статье изначально были основаны на версии ESLint v6, но недавно была выпущена версия ESLint v7. Не волнуйтесь, даже в версии 7 ESLint работает без каких-либо изменений. Если вас интересует, что было изменено или добавлено, вы можете ознакомиться с примечаниями к выпуску ESLint v7.

Следите за новыми постами по любимым темам

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *