Основное время выполнения Линтера с хорошо выбранным набором встроенных правил. Настраивается с вашими собственными правилами, процессорами, формами, общими конфигурациями и модулями плагина.
Пожалуйста, обратитесь к документам для подробного объяснения доступных правил, конфигурации и использования.
Века
Официальный процессор для однофакторных компонентов Vue (SFC). Извлекает содержимое сценария из ваших *.vue Files для Linting.
Хеймдалл
Совместимость, чтобы разрешить использование правил и форматеров TSLINT во время выполнения Wotan.
Valtýr
Заставьте Wotan вести себя почти как Tslint. Повторно используйте свой существующий tslint.json без каких -либо изменений.
Bifröst
Позволяет авторам правил и форматер TSLINT предоставить свой пакет для использования внутри Wotan. Правила и форматирования, которые используют Bifröst, не нужны Хеймдаллу, чтобы функционировать правильно.
Имир
Предоставляет основные типы для пользовательских правил и авторов плагинов.
Мимир
Содержит все основные правила, форматчики и проекты конфигурации.
Митотин
Плагин Languageservice для TypeScript. Обеспечивает линейку в режиме реального времени, пока вы вводите.
Дополнительная документация
Понимание API TypeScript
Написание правил
Правила тестирования
Использование местных правил
Написание общих конфигураций
Используя API
Рецепты
Linting Vue -файлы с правилами TSLINT
Замена для tslint --type-check
Обнаружение неиспользованных переменных
О чем это?
Что случилось с этими именами?
Норвейская мифология:
Fimbullinter происходит от Fimbulwinter, ужасную 3 года, продленную зиму, которая предшествует событиям Рагнарука. «Fimbul» означает «Великий», «Линтер» - это инструмент, который обнаруживает и предупреждает о определенных моделях кодирования.
Вотан -одно из многих имен Одина, отца. Вы также можете знать его по имени Воден, Водан, Уэнсли и т. Д. Воден - жертвенный бог, кровожадный и жестокий. Он постоянно стремится к мудрости. С своего престола он может видеть все в девяти мирах.
Ве - самый младший из трех беспокоит Воден, Вили и В., которые вместе убили гигантского Имира и создали девять миров из своего тела.
Для первой человеческой пары, спросить и эмбла, Один дал душу и жизнь; Вили дал остроумие (интеллект) и чувство прикосновения; и Vé дал лицо (внешность, выражение лица), речь, слух и зрение.
Хеймдалл (также известный как Хеймдалл), расположенный, где Burning Rainbow Bridge Bifröst встречает небеса, следит за наступлением Рагнарука.
Bifröst - это горящий радужный мост, который соединяет мир людей с царством богов.
Valtýr из «valr» (мертвых, убитых в бою) и «týr» (Бог), означает Бога убитого и часто используется для обозначения Одина.
Имир - это гигант, чье тело был создан весь мир. Он предок всего Йотнера.
Мимир («Запоминание, мудрый»), известный своими знаниями и мудростью. Бог Один несет вокруг головы Мимира, и он читает секретные знания и совета ему.
Митотин (на самом деле «митодинн», что означает «дозатор судьбы») вводит правила, в которых их не было. Заполняет место Одина во время его путешествий на иностранные земли.
Почему еще один линтер?
Это пытается избежать дизайнерских решений других линтеров, которые оказались проблематичными:
Избегайте конфликтов имен путем префикса имен правил в зависимости от пакета, из которого они приходят.
Tslint помещает все правила в глобальное пространство имен и ищет их во всех доступных каталогах правил. Порядок каталогов имеет значение, в то время как основные правила переопределяют приоритет.
Eslint позволяет локальный каталог правил в качестве флага CLI. Правила в этом каталоге могут переопределить основные правила.
Зависимости файлов конфигурации разрешаются относительно этого файла.
Tslint уже делает это.
Eslint не поддерживает это.
Нет различий между общими конфигурациями и плагинами. На самом деле оба являются просто расширяемыми конфигурациями, которые могут при желании предоставлять каталоги правил, настройки, правила и процессоры.
TSLINT позволяет вам выбирать между extends и rulesDirectory . Справочник по правилам пакета является подробной информацией и не должен быть частью конфигурации пользователя.
Eslint обрабатывает конфигурации и плагины совершенно разные. На самом деле они пытались установить общие конфигурации в пользу плагинов.
Ленивая загрузка правил для сокращения времени запуска.
Tslint уже делает это.
Eslint ожидает, что плагины будут предоставлять правила как уже загруженные объекты. Это вызывает много накладных расходов, если вы используете только несколько правил большого пакета.
Кэширование доступа и конфигурации файловой системы. Поскольку кэш является службой DI, пользователи API могут очистить кэш при необходимости.
Поддержка процессоров с самого начала. Включение вкладки *.vue файлов и многое другое.
Псевдонимы для правил с конфигурацией. Может использоваться для обработки правил, таких как no-resticted-syntax Eslint как отдельные именованные правила для каждой опции конфигурации.
Весь API питается контейнером DI. Это позволяет легко вводить другой сервис. Вы даже можете использовать плагины через CLI, чтобы вводить различные сервисы.
«Глобальный» файл конфигурации (помимо .wotanrc.yaml ) для по умолчанию CLI и конфигурации плагина: .fimbullinter.yaml . Этот файл также может использоваться плагинами редактора, поэтому нет необходимости дублировать общую конфигурацию.
У Eslint нет такого файла, и он отказался добавить его в будущем. Такие инструменты, как standard или xo не должны существовать, если вам просто нужно было создать такой файл конфигурации с помощью по умолчанию CLI.
Tslint Startet, чтобы внести его в свой tslint.json , который приводит к запутанным пользователям.
Сообщите о неиспользованных и избыточных включении и отключении комментариев (или их частей) с помощью --report-useless-directives .
Eslint сообщает только о неиспользованных комментариях. В нем сообщается только комментарии, которые совершенно не используются. Избыточные комментарии не сообщаются, а также включают комментарии для несуществующих правил.
Tslint не поддерживает это.
Различия в TSLINT
Чтобы расширить плагин или общий конфигурацию, используйте extends: plugin-name . Имя будет разрешено в соответствии с алгоритмом разрешения модуля узла относительно файла конфигурации.
Чтобы использовать правила, поддерживаемые в вашем проекте, используйте rulesDirectory: {"my-prefix": "./path/to/rules"} и настройка их как my-prefix/rule-one: "error" . Справочник правил - это путь относительно файла конфигурации.
Переопределения: вы можете переопределить основную кофигурацию, указав один или несколько переопределений. Если имя файла соответствует шаблону шаровика переопределения, применяются все настройки, предоставленные этим переопределением. Переопределения обрабатываются по порядку, а затем переопределяет настройки переопределения из предыдущих переопределений.
Паттерны соответствуют по сравнению с файлом конфигурации, в котором они указаны.
Паттерны без смены совпадают только с базовым именем каждого файла.
Чтобы ограничить соответствие текущему каталогу, префикс шаблон с ./ .
Отрицательные шаблоны могут быть использованы для вычтения из совпадений предыдущих шаблонов.
linterOptions.exclude -> exclude
Исключения не переопределяются при расширении конфигурации.
Соответствие шаблона следует те же правила, что и переопределения (см. Выше).
Поддержка JSON5 для файлов конфигурации.
Независимые от правила настроения, которые правила и процессоры могут забрать.
Процессоры, даже поддерживают --project .
Псевдонимы, см. Выше
Разменяемый и безопасный подход к исправлению:
Не исправляет файлы с помощью синтаксических ошибок.
Исключает перекрывающиеся замены, чтобы предотвратить уничтожение вашего кода.
Запускает настраиваемое число итераций на файл, чтобы применить противоречивые изменения в следующей итерации.
Остановки, если исправления будут вводить синтаксические ошибки.
Исправление с помощью --projectне создает всю программу с нуля, что делает ее яростно быстрым.
Тестирование
Тесты настроены в файлах JSON, которые могут настроить все, что вы можете указать, хотя CLI
Тестовые файлы не содержат разметки ошибок. Это избегает синтаксических ошибок и облегчает их поддержание. Результаты Lint и фиксированный содержимое хранятся в отдельных базовых файлах.
Один и тот же код может быть протестирован с различными настройками.
Поддерживает ссылки на проект TypeScript.
Загружает значения по умолчанию для параметров CLI от .fimbullinter.yaml .
Не использует информацию типа в неконтролируемых файлах JavaScript ( // @ts-nocheck или "checkJs": false ).
Отчеты о неиспользованных и избыточных включении и отключении комментариев с помощью --report-useless-directives .
Поддерживаемая среда
Этот проект работает на всех активно поддерживаемых версиях node.js.
Этот проект официально поддерживает последнюю 3 стабильную версию TypeScript. На момент написания это 3,0 - 3.2. Он должен работать с ночными сборками TypeScript ( typescript@next ), но нет никакой гарантии.
Пользовательские правила должны, по крайней мере, использовать ES6 для поддержки местных классов. В противном случае вы сталкиваетесь с проблемами при попытке расширить классы, экспортируемые из любого из пакетов.
Семантическое управление версиями (политика SEMVER)
️ Следующая политика применяется только для выпусков, предназначенных для того, чтобы быть наступлением 1.x и следующие выпуски. Каждый выпуск в диапазоне 0.x считается экспериментальным. Там может и будет нарушать изменения API без осмотра.
Теоретически каждое изменение в правиле может нарушить пользователей и может считаться нарушающим изменением. Чтобы избежать выпуска новой крупной версии для каждого исправления ошибок, у нас есть несколько разные рекомендации, как указано ниже.
PreLeleases (ночные сборки)
не гарантированно будет стабильным
Tagged, как next на NPM, так что вы можете установить @fimbul/wotan@next
содержит последние изменения, предназначенные для следующего выпуска
x.0.0-dev* содержит все изменения, включая разрывы для следующей крупной версии
xy0-dev* содержит все изменения для следующей незначительной версии
нет никаких пререлиатов для патч -версий
Патч -релизы
Исправляет сбои
Исправляет регрессии
Рефактор внутренней функциональности, которые не изменяют поведение пользователя.
Незначительные выпуски
Добавляет новые правила, параметры правил, форматер, процессоры, APIS
Правила могут добавить новые чеки, которые могут привести к новым выводам
Новые правила и параметры включены в wotan:latest
Правила могут изменить свои обнаруженные сообщения
Форматер, предназначенные для потребления человека (например, stylish ), могут изменить свой выход
Правила, варианты правил, форматчики, процессоры и API могут быть оправданы
Новые параметры конфигурации могут быть добавлены в файлы конфигурации
Крупные выпуски
Содержит нарушающие изменения API
Удаляет ранее устаревшие правила, варианты, форматер и т. Д.
Форматер, предназначенные для потребления машины (например, json или tap ) могут изменить свой выход
wotan:recommended обновлять контент wotan:latest
Расписание выпуска
В настоящее время нет фиксированного графика выпуска. Ночные сборки публикуются каждую ночь, если в мастер есть изменения. Платаные выпуски опубликованы, как только ошибки идентифицируются и исправлены. Незначительные релизы публикуются каждую неделю или две, если в мастер есть изменения. Основные выпуски опубликованы после того, как накапливается достаточное количество разрыва.
