Tslint: Дорожная карта: TSLint -> ESLint

Созданный на 23 февр. 2019  ·  52Комментарии  ·  Источник: palantir/tslint

Как вы, возможно, прочитали в этом сообщении в блоге , мы планируем прекратить поддержку TSLint в 2019 году и поддержать переход на ESLint в качестве стандартного линтера как для TypeScript, так и для JavaScript. Это не будет немедленным прекращением поддержки; напротив, предстоит проделать большую работу, чтобы обеспечить плавный переход на новый инструментарий без каких-либо регрессий. В TSLint есть функции, наборы тестов и удобства, которые мы надеемся сохранить при миграции. Может быть период времени, когда эти два инструмента пересекаются, и первопроходцам TSLint рекомендуется запускать _оба_ линтера, чтобы обеспечить полное покрытие проверки кода (в разумной степени, чтобы производительность сильно не пострадала).

Я буду закрывать некоторые запросы функций в этом репозитории, которые теперь кажутся выходящими за рамки, потому что мы ожидаем, что они будут обработаны в дорожной карте ESLint / typescript-eslint . Одним из примеров категории правил, для которых __запросы новых функций__ с наибольшей вероятностью будут закрыты/отклонены, являются правила форматирования . Я уже давно предлагал разделить эти правила, потому что мы используем Prettier в Palantir и считаем его лучшим инструментом для форматирования кода.

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


Обновление (июнь 2019 г.): более конкретный график дорожной карты, согласованный с @JoshuaKGoldberg и tslint-contrib-microsoft:

  • __1 августа 2019 г.__: прекратите принимать новые _core_ правила. По-прежнему принимайте исправления ошибок, незначительные функции и улучшения правил. Пользовательские правила всегда доступны и могут поддерживаться вне этого репозитория.
  • __1 ноября 2019 г. _: прекратите принимать улучшения функций или правил (за исключением тех, которые упрощают переход на typescript-eslint). По-прежнему принимать исправления ошибок.
  • __1 января 2020 г.__: Прекратите принимать что-либо, кроме исправлений безопасности и исправлений сбоев, вызванных нарушением изменений TypeScript.
  • __1 декабря 2020 г.__: прекратите принимать любые PR 🎉

Обновление (август 2019 г.): см. tslint-to-eslint-config для команды CLI, которая переносит файлы конфигурации TSLint в файлы конфигурации ESLint.


Обновление (март 2020 г.): добавлены _ «и исправления для сбоев, вызванных нарушением изменений TypeScript»_ до крайнего срока 1 января, после обсуждения в # 4914.

Documentation

Самый полезный комментарий

Было бы здорово иметь команду CLI, которая переносит tslint.json в eslint.json, сопоставляя эквивалентные правила и параметры. В идеале было бы удалить правила, которые можно перенести из tslint.json, и сохранить правила, которые еще не имеют эквивалента (или не поддерживают используемые параметры), чтобы правило можно было запускать идемпотентно многократно с течением времени, пока tslint.json не станет пустым. в какой-то момент, и мы можем полностью положиться на ESLint.

Все 52 Комментарий

Было бы здорово иметь команду CLI, которая переносит tslint.json в eslint.json, сопоставляя эквивалентные правила и параметры. В идеале было бы удалить правила, которые можно перенести из tslint.json, и сохранить правила, которые еще не имеют эквивалента (или не поддерживают используемые параметры), чтобы правило можно было запускать идемпотентно многократно с течением времени, пока tslint.json не станет пустым. в какой-то момент, и мы можем полностью положиться на ESLint.

Хорошие новости.
Ребята из ESLint уже запустили проект typescript-eslint для поддержки TS.
Они тоже ищут помощи. Вот заявление. .

что будет означать написание правил tslint после миграции?

Планируется ли перенести eslint с JS на TS? Ненавижу это говорить, но если eslint не перенесут на ts, писать правила будет не так приятно.

Плохо, мы будем использовать не eslint, мы будем использовать typescript-eslint, в этом больше смысла. дайте мне знать, если я могу быть чем-то полезен.

можно ли сослаться на этот план, чтобы исключить его из readme.md в репозитории? Похоже, что об этом плане знают только определенные люди, и это не является общеизвестным фактом. Спасибо!

@joeyj-msft действительно, добавлено adidahiya в a395501739bf7f0f166e5b0ccb355c0e9500445a.

Было бы неплохо иметь некоторый «резюме» правил TSLint (https://palantir.github.io/tslint/rules/), доступный в typescript-eslint . Не знаю, должен ли это быть флаг «ESLint» в palantir или новый список на https://github.com/typescript-eslint/typescript-eslint. Но это помогло бы решить, готов ли проект к переезду или нет.

@JoshuaKGoldberg Я перехожу с tslint на typescript-eslint. Я использовал TSLint для создания пользовательских правил для своего проекта. Как я могу приступить к созданию пользовательских правил, как мы это делали в TSLint?

Мой проект создает файлы Javascript, а также файлы Typescript, поэтому мне нужно создать для них только одно правило?

@moulikcipherX спасибо за вопрос, отличные вопросы!

Вы можете использовать свои правила TSLint в ESLint, используя typescript-eslint/packages/eslint-plugin-tslint . Он обертывает конфигурацию TSLint и анализирует ваш код с помощью TSLint.

Чтобы написать правила в ESLint, см. typescript-eslint/packages/eslint-plugin . На этом README.md есть список всех поддерживаемых правил _(список стал довольно большим!)_. В ROADMAP.md есть сопоставление существующих правил TSLint с новыми эквивалентами.

Спасибо @JoshuaKGoldberg.

Поэтому я могу в дальнейшем использовать те же методы для создания пользовательских правил для TypeScript, что и в TSLint.

Примечание. Я только что обновил исходный пост в этой теме, указав более конкретную временную шкалу дорожной карты. Прокрутите страницу вверх, чтобы увидеть ее.

Э-э, разве сообщение в блоге не должно быть также в https://github.com/palantir/tslint/tree/gh-pages/_posts и связано с https://github.com/palantir/tslint/blob/master/ README.md ?

@SamB блог на веб-сайте gh-pages довольно устарел, мы его не обновляли. И сообщение в блоге связано в верхней части README.

@adidahiya @JoshuaKGoldberg
Я хочу внести свой вклад в проект typescript-eslint, с чего мне начать?

Будет ли эквивалентное преобразование пользовательских правил tslint в пользовательские правила eslint поддерживаться в будущем typescript-supported-eslint ?

Я пытаюсь сказать, что у меня есть определенная команда CLI для преобразования JS-файлов custom-tslint-rule в соответствующие правила линтинга, совместимые с eslint. Это очень поможет, так как переопределение правила tslint для eslint будет действительно сложной задачей...

@a20185 a20185 да, теперь это существует! https://github.com/typescript-eslint/tslint-to-eslint-config

Спасибо за создание такого блестящего инструмента, и я желаю вам всего наилучшего в ваших будущих приключениях. Говоря о приключениях, это определенно было, не так ли?

В любом случае, всего тебе доброго,
Воля

Учитывая, что мы приближаемся к концу 2019 года (год, когда это репо предположительно устарело), ​​сейчас самое время добавить флаг устаревшего в NPM, чтобы новые установки были направлены на ESLint.

Также было бы полезно сделать ридми более очевидным (верхний уровень) и связать пользователей с typescript-eslint.

Планируете ли вы сделать это сейчас, когда ESLint охватывает почти все распространенные варианты использования?

Я также думаю и надеюсь, что когда tslint устаревает, eslint подвергается большему давлению, и сообщество уделяет ему больше внимания.

tslint-to-eslint-config помогает преобразовать tslint.json в .eslinerc.js , но не может
не может позаботиться о встроенных tslint:disable:<rule> , кроме того, некоторые правила плохо настроены или еще не поддерживаются eslint.

При переходе с tslint на eslint все еще есть некоторые преимущества, в чем преимущество использования eslint для файлов машинописного текста? Чтобы добиться большей согласованности между сообществом машинописи и сообществом javascript?
Если в проекте используется только машинописный текст без файлов javascript, есть ли какие-либо преимущества после выполнения миграции?

tslint-to-eslint-config помогает преобразовать tslint.json в .eslinerc.js , но не может
не может позаботиться о встроенных tslint:disable:<rule>

Действительно: https://github.com/typescript-eslint/tslint-to-eslint-config/issues/136
Вы можете добавить его, если хотите! На странице https://github.com/typescript-eslint/tslint-to-eslint-config/pull/246 находится незавершенный PR, который может помочь.

При переходе с tslint на eslint все еще есть некоторые преимущества, в чем преимущество использования eslint для файлов машинописного текста?

Вы можете увидеть причины, перечисленные в сообщении блога, упомянутом в верхней части этой темы.

@beenotung

TSLint всегда был ограничен по сравнению с ESLint, у него никогда не было правил, которых не было у ESLint. Не говоря уже о плагинах и гораздо большем сообществе/поддержке, которые всегда были у ESLint. Кроме того, у многих из нас есть красиво настроенный eslintrc , который мы используем везде, что делает любой проект TSLint несоответствием, которое необходимо исправить (с помощью неустаревшего инструмента).

Если в ESLint чего-то не хватает, что есть в TSLint, лучше поднять его, чтобы его можно было реализовать, чем продолжать использовать устаревший инструмент.

Спасибо, что рассказали больше о eslint, я вижу преимущества использования eslint.

На самом деле я пытался перейти с tslint на eslint, но кажется, что некоторые края нельзя легко исправить, потому что eslint не имеет концепции типа (поэтому отступ для универсального типа нарушен).

Что касается поддержки инструментов на eslint (особенно подсказки IDE в файле конфигурации). Я хотел бы внести свой вклад в один прекрасный день, но у меня нет ни опыта, ни свободы, чтобы работать над этим в настоящее время. (По крайней мере, это не первое место в моем списке, потому что tslint все еще работает нормально)

Кажется, менее болезненным способом является использование tslint для файлов typescript и eslint для файлов javascript, чтобы оба мира могли наслаждаться своей «согласованностью».

Поскольку npm заявляет, что TSLint устарел и вместо него используется ESLint , я предполагаю, что миграция завершена.
Не следует ли закрыть этот вопрос?

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

Приведенный выше пост в блоге не посвящен техническим подробностям о typescript-eslint .
Пользователи TSLint могут узнать больше о том, как работает typescript-eslint ?

В целом во всем файле typescript-eslint/README есть все необходимое для прозрачного перехода.

Есть ли причина, по которой сам пакет не помечен как устаревший в npm? Например, запрос ?

Версия @niklasR 6.0.0 была помечена как устаревшая в NPM, после чего начался ад.

Проверьте # 4919 и # 4914 .

Мы _хотим_ чтобы весь ад вырвался на свободу 😛... люди должны прекратить использовать TSLint.

Похоже, мы просто никогда явно не помечали новые версии как устаревшие; см. историю версий на https://www.npmjs.com/package/tslint :
Screenshot showing 6.0.0 as deprecated on npm but later versions not

У меня нет разрешений - @adidahiya ?

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

npm deprecate tslint@^6.0.0 "TSLint has been deprecated in favor of ESLint. Please see https://github.com/palantir/tslint/issues/4534 for more information."

... но я полагаю, что это не так. Я пошел дальше и отказался от более новых.

@adidahiya Спасибо, я открыл вопрос о документах NPM здесь: https://github.com/npm/cli/issues/1165 .

Должны ли старые версии также быть устаревшими? Точно так же, как это делает запрос?

Причина, по которой я спрашиваю, заключается в том, что мы собираемся перенести наши пакеты в ESLint, но довольно часто используем TSLint ^5, и было бы неплохо использовать наш существующий процесс, чтобы просто сканировать наши (300+) репозитории на наличие уведомления об устаревании, чтобы пометить все, что требует миграции.

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

Было бы неплохо, если бы пользователи отображали что-то очень четкое об устаревании TSLint на странице github https://palantir.github.io/tslint/?

Было бы неплохо, если бы пользователи отображали что-то очень четкое об устаревании TSLint на странице github https://palantir.github.io/tslint/?

Это именно то, чего я ждал! пожалуйста, кто-нибудь дайте четкие пошаговые инструкции по переходу с tslint на eslint

Веб-сайт документации TSLint давно не обновлялся, но README этого репозитория актуален, и в файле typescript-eslint README содержится довольно много полезной информации, включая пошаговое руководство по миграции.

Исправление сообщения об ошибке
[https://stackoverflow.com/questions/61605380/angular-9-issue-unable-to-run-the-initial-application]
npm установить чокидар
очистить кеш npm --force
npm install -g @angular/ cli@latest

install error
Здравствуйте, команда Angular, я новичок в angular, пожалуйста, помогите мне с ошибкой, которую я получаю при попытке создать новый проект.

Спасибо.

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

Спасибо.

Вы находитесь не в том месте
Это palantir , а не angular
Пожалуйста, создайте задачу на https://github.com/angular/angular/issues .
Или, что еще лучше, поищите, есть ли уже проблема, решите эту проблему.
Рад помочь, увидимся

Как бы я ни был ошеломлен тем, что они просят «здесь» о помощи по Angular. Я очень впечатлен их логотипом, похожим на розетку в Великобритании.

@JoshuaKGoldberg Спасибо!

Также должен наступить день, когда вы заархивируете/заблокируете этот репозиторий.

Это никогда не должно нуждаться в изменении кода снова. Если кто-то найдет ошибку сейчас, решение состоит в том, чтобы использовать ESLint, а не копаться в этом давно устаревшем проекте.

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

Я думаю, что ts-lint больше не следует использовать вместо eslint с сентября 2020 г.

Если ваш проект все еще использует ts-lint, рассмотрите возможность использования
проверка https://github.com/typescript-eslint/tslint-to-eslint-config

но typescript-eslint на самом деле не говорит, что не так https://github.com/typescript-eslint/typescript-eslint/blob/master/docs/getting-started/linting/FAQ.md#why -dont-i-see -typescript-ошибки-в-моем-eslint-выводе

😢

но typescript-eslint на самом деле не говорит, что не так https://github.com/typescript-eslint/typescript-eslint/blob/master/docs/getting-started/linting/FAQ.md#why -dont-i-see -typescript-ошибки-в-моем-eslint-выводе

😢

Я думаю, что это более или менее верно даже для TSLint, и почему даже с TSLint мы также вызываем tsc --noEmit в наших сценариях линтинга.

Я создал новое угловое приложение с версией 8, и с ним поставляется tslint по умолчанию. Я начал использовать конфигурацию ts для реализации хаски. Мой вопрос: обязательно ли переходить на typescript-eslint в соответствии с рекомендациями, учитывая тот факт, что я буду использовать Angular 8 в своем проекте в течение нескольких лет?

@mayankkalbhor Как вы видели, по умолчанию в Angular по-прежнему используется TSLint. Я полагаю, что это будет до Angular 11 или более поздней версии, пока все конфигурации по умолчанию в Angular CLI не будут настроены для ESLint, см. дорожную карту: https://angular.io/guide/roadmap#migration -to-eslint.

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

Я считаю, что путь по умолчанию для разработчиков Angular — ждать, пока Angular включит сценарии миграции в какое-то будущее обновление Angular, вероятно, с Angular 10 на 11 или с 11 на 12.

Однако любой может самостоятельно перейти на ESLint. Единственный реальный блокатор для самостоятельной миграции — это если у вас есть время и вы не возражаете против потери функций, которых в настоящее время нет в эквивалентных конфигурациях ESLint. Там, где ранее были некоторые конфигурации linting через Codelyzer , и теперь у нас есть надвигающаяся замена здесь: angular-eslint

Поскольку мы приближаемся к окончанию срока службы программного обеспечения, было бы здорово, если бы в каждом документе правил была ссылка на правило замены в документации typescript-eslint, точно так же, как это делает typescript-eslint в обратном порядке.

Означает ли это, что я не смогу использовать tslint в своих проектах после 1 января 2021 года? В настоящее время мои сборки используют tslint. Я не вижу команды для установки tslint на веб-сайте npm. И он говорит, что tslint устарел. Может ли кто-нибудь ответить на мои вопросы?

Спасибо.

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

Как моя последняя проверка, tslint поддерживает больше типов автоматического исправления, поэтому я рекомендую запустить «tslint --fix» перед запуском eslint.

Возможно, за это время что-то изменилось.

Я разберу этот код.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги