Tslint: Feuille de route : TSLint -> ESLint

Je serais formidable d'avoir une commande CLI qui migre un tslint.json vers un eslint.json, en mappant des règles et des options équivalentes. Idéalement, cela supprimerait les règles pouvant être migrées depuis tslint.json et conserverait les règles qui n'ont pas encore d'équivalent (ou qui ne prennent pas en charge les options utilisées), afin que la règle puisse être exécutée de manière idempotente à plusieurs reprises dans le temps jusqu'à ce que tslint.json devienne vide. à un moment donné et nous pouvons entièrement compter sur ESLint.

Bonnes nouvelles.
Les gars d'ESLint ont déjà lancé le projet dactylographié-eslint pour prendre en charge TS.
Ils recherchent également de l'aide. Voici la déclaration. .

que signifiera l'écriture des règles tslint après la migration ?

Est-il prévu de migrer eslint de JS vers TS ? Je déteste le dire, mais si eslint n'est pas migré vers ts, ce ne serait pas aussi agréable d'écrire des règles.

Mon mauvais, ce n'est pas eslint que nous utiliserons, nous utiliserons dactylographié-eslint, c'est plus logique. faites-moi savoir si je peux vous être utile.

serait-il possible de faire référence à ce plan d'abandon du fichier readme.md dans le référentiel ? Il semble que seules certaines personnes connaissent ce plan et ne sont pas de notoriété publique. Merci!

@joeyj-msft en effet, ajouté dans a395501739bf7f0f166e5b0ccb355c0e9500445a par adidahiya.

Ce serait bien d'avoir un "récapitulatif" des règles TSLint (https://palantir.github.io/tslint/rules/) disponible en typescript-eslint . Je ne sais pas s'il devrait s'agir d'un drapeau "ESLint" sur palantir ou d'une nouvelle liste sur https://github.com/typescript-eslint/typescript-eslint. Mais cela aiderait à décider si un projet est prêt à bouger ou non.

@Maximebpro voir https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/ROADMAP.md :+1 :

@JoshuaKGoldberg Je passe de tslint à tapuscrit-eslint. J'utilisais TSLint pour créer des règles personnalisées pour mon projet. Comment puis-je procéder à la création de règles personnalisées comme nous l'avons fait dans TSLint ?

Mon projet crée des fichiers Javascript ainsi que des fichiers Typescript, je dois donc créer une seule règle pour eux ?

@moulikcipherX merci d'avoir posé, bonnes questions !

Vous pouvez utiliser vos règles TSLint dans ESLint en utilisant typescript-eslint/packages/eslint-plugin-tslint . Il encapsule une configuration TSLint et peluche votre code à l'aide de TSLint.

Pour écrire des règles en ESLint, voir typescript-eslint/packages/eslint-plugin . Ce README.md contient une liste de toutes leurs règles prises en charge _(la liste est devenue assez longue !)_. Le ROADMAP.md contient un mappage des règles TSLint existantes vers les nouveaux équivalents.

Merci @JoshuaKGoldberg.

Je peux donc utiliser les mêmes méthodes pour créer des règles personnalisées pour TypeScript comme dans TSLint.

Remarque : Je viens de mettre à jour le message d'origine dans ce fil de discussion avec une chronologie plus concrète de la feuille de route. Faites défiler vers le haut de cette page pour le voir.

Euh, le billet de blog ne devrait-il pas également être dans https://github.com/palantir/tslint/tree/gh-pages/_posts , et lié à partir de https://github.com/palantir/tslint/blob/master/ LISEZMOI.md ?

@SamB le blog du site gh-pages est assez obsolète, nous ne l'avons pas mis à jour. Et le billet de blog est lié en haut du README.

@adidahiya @JoshuaKGoldberg
Je veux contribuer au projet dactylographié-eslint alors par où dois-je commencer ?

@moulikcipherX https://github.com/typescript-eslint/typescript-eslint#how-can-i-help

La transformation équivalente des règles tslint personnalisées en règles eslint personnalisées sera-t-elle prise en charge à l'avenir typescript-supported-eslint ?

Ce que j'essaie de dire, c'est d'avoir une certaine commande CLI pour convertir les fichiers JS de custom-tslint-rule en règles de lint compatibles eslint correspondantes. Cela aidera beaucoup car réimplémenter la règle de tslint à eslint sera un travail vraiment difficile ...

@a20185 , oui, ça existe maintenant ! https://github.com/typescript-eslint/tslint-to-eslint-config

Merci d'avoir créé un outil aussi brillant, et je vous souhaite le meilleur dans vos futures aventures. En parlant d'aventures, celle-ci en a certainement été une, n'est-ce pas ?

Quoi qu'il en soit, tout le meilleur pour vous,
Sera

Étant donné que nous arrivons à la fin de 2019 (l'année où ce référentiel était censé être obsolète), le moment est peut-être venu d'ajouter le drapeau obsolète dans NPM afin que les nouvelles installations soient dirigées vers ESLint.

Il serait également utile de rendre la notice readme un peu plus évidente (niveau supérieur) et de lier les utilisateurs à dactylographier-eslint.

Envisagez-vous de le faire maintenant que presque tous les cas d'utilisation courants ont été couverts par ESLint ?

Je pense aussi et j'espère que lorsque tslint est obsolète, eslint subit plus de pression et que la communauté se concentre davantage dessus

Le tslint-to-eslint-config aide à convertir tslint.json en .eslinerc.js mais il ne peut pas
ne peut pas prendre en charge inline tslint:disable:<rule> , de plus, certaines règles ne sont pas bien configurées ou ne sont pas encore prises en charge par eslint.

Il y a encore quelques bords lors de la migration de tslint vers eslint, quel est l'avantage d'utiliser eslint pour les fichiers dactylographiés ? Pour obtenir une meilleure cohérence entre la communauté dactylographiée et la communauté javascript ?
Si un projet n'utilise que du tapuscrit, sans aucun fichier javascript, y a-t-il encore un avantage après la migration ?

Le tslint-to-eslint-config aide à convertir tslint.json en .eslinerc.js mais il ne peut pas
ne peut pas prendre en charge les tslint:disable:<rule> en ligne

En effet : https://github.com/typescript-eslint/tslint-to-eslint-config/issues/136
Vous êtes invités à participer pour l'ajouter si vous le souhaitez ! Il y a un travail en cours PR à https://github.com/typescript-eslint/tslint-to-eslint-config/pull/246 qui pourrait avoir besoin d'aide.

Il y a encore quelques bords lors de la migration de tslint vers eslint, quel est l'avantage d'utiliser eslint pour les fichiers dactylographiés ?

Vous pouvez voir les raisons énumérées dans le billet de blog mentionné en haut de ce fil.

@beenotung

TSLint a toujours été limité par rapport à ESLint, il y a tout un tas de règles qu'il n'a jamais eues, ce qu'ESLint a fait. Sans parler des plugins et de la communauté / support beaucoup plus large qu'ESLint a toujours eu. De plus, beaucoup d'entre nous ont un eslintrc bien configuré que nous utilisons partout, faisant de tout projet TSLint une incohérence qui doit être corrigée (en utilisant un outil non obsolète).

S'il manque quelque chose dans ESLint que TSLint a, il est préférable de l'augmenter pour qu'il puisse être implémenté plutôt que de continuer à utiliser un outil obsolète.

Merci d'avoir soulevé plus de contexte sur eslint, je vois l'avantage d'utiliser eslint.

J'ai en fait essayé de migrer de tslint vers eslint mais il semble que certains bords ne puissent pas être corrigés facilement car eslint n'a pas le concept de type (d'où l'indentation pour le type générique est cassée).

Concernant la prise en charge des outils sur eslint (en particulier les conseils IDE sur le fichier de configuration). J'aimerais pouvoir contribuer un jour, mais je ne suis ni expérimenté ni libre de travailler là-dessus actuellement. (Au moins ce n'est pas dans le haut de ma liste car bon, tslint fonctionne toujours bien)

Il semble que la manière la moins pénible consiste à utiliser tslint pour les fichiers dactylographiés et eslint pour les fichiers javascript, afin que les deux mondes puissent profiter de leur "cohérence".

Comme npm indique que TSLint est obsolète et utilise ESLint à la place , je suppose que la migration est terminée.
Ce sujet ne devrait-il pas être clos ?

@cdalexndr , il est toujours utile d'avoir ce problème ouvert pour que les gens se renseignent sur la justification de la dépréciation et lisent les dernières mises à jour.

Le billet de blog dû ci-dessus ne se concentre pas sur les détails techniques de typescript-eslint .
Les utilisateurs de TSLint peuvent en savoir plus sur Comment fonctionne typescript-eslint ?

En général, l'ensemble du fichier typescript-eslint/README contient tout le nécessaire pour une transition transparente.

Y a-t-il une raison pour laquelle le package lui-même n'est pas marqué comme obsolète sur npm ? Comme par exemple demande ?

La version 6.0.0 de @niklasR a été marquée comme obsolète dans NPM, puis l'enfer s'est déchaîné.

Découvrez #4919 et #4914 .

Nous _voulons_ que tout l'enfer se déchaîne cependant 😛... les gens devraient arrêter d'utiliser TSLint.

Il semble que nous n'ayons jamais explicitement marqué les nouvelles versions comme obsolètes ; voir l'historique des versions sur https://www.npmjs.com/package/tslint :

Je n'ai pas les permissions - @adidahiya ?

Oh, étrange, je pensais que la documentation ici suggérait que cette commande rendrait obsolètes toutes les futures versions potentielles qui entrent dans la gamme :

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."

... mais je suppose que ce n'est pas le cas. Je suis allé de l'avant et j'ai déconseillé les plus récents.

@adidahiya Merci, j'ai ouvert un problème sur la documentation NPM ici : https://github.com/npm/cli/issues/1165

Les anciennes versions doivent-elles également être obsolètes ? De même comment demande -t-il ?

La raison pour laquelle je pose la question est que nous envisageons de migrer nos packages vers ESLint, mais que nous utilisons beaucoup TSLint ^ 5, et ce serait bien d'utiliser notre processus existant pour simplement analyser nos (300+) dépôts pour des avis d'obsolescence pour signaler ceux qui doivent être migrés.

Les dépréciations se sont toujours et uniquement appliquées aux versions existantes ; si vous souhaitez que les nouvelles versions soient obsolètes, vous devez toujours les obsolètes manuellement après la publication.

Ce ne serait pas bien pour les utilisateurs d'afficher quelque chose de très clair sur la dépréciation de TSLint sur la page github https://palantir.github.io/tslint/?

Ce ne serait pas bien pour les utilisateurs d'afficher quelque chose de très clair sur la dépréciation de TSLint sur la page github https://palantir.github.io/tslint/?

C'est exactement ce que j'attendais ! s'il vous plaît quelqu'un présente des instructions claires étape par étape sur la migration de tslint à eslint

Le site Web de documentation TSLint n'a pas été mis à jour depuis un certain temps, mais le fichier README de ce dépôt est à jour et il y a beaucoup d'informations utiles, y compris un guide étape par étape pour la migration, dans le fichier README dactylographié-eslint .

Correction du message d'erreur
[https://stackoverflow.com/questions/61605380/angular-9-issue-unable-to-run-the-initial-application]
npm installer chokidar
nettoyage du cache npm --force
npm install -g @angular/ cli@latest

Bonjour l'équipe angulaire, je suis nouveau sur angular, aidez-moi s'il vous plaît avec l'erreur que je reçois en essayant de créer un nouveau projet.

Merci.

Bonjour l'équipe angulaire, je suis nouveau sur angular, aidez-moi s'il vous plaît avec l'erreur que je reçois en essayant de créer un nouveau projet.

Merci.

Vous êtes au mauvais endroit
C'est palantir et non angular
Veuillez créer un problème sur https://github.com/angular/angular/issues
Ou encore mieux, recherchez s'il existe déjà un problème concernant ce problème
Au plaisir de vous aider, à bientôt

Autant je suis abasourdi par le fait qu'ils demandent "ici" de l'aide angulaire. Je suis assez impressionné que leur logo ressemble à la prise de courant britannique.

@JoshuaKGoldberg Merci !

Le jour devrait également venir où vous archiverez/verrouillerez ce référentiel.

Il ne devrait plus jamais avoir besoin d'un changement de code. Si quelqu'un trouve un bogue maintenant, la solution consiste à utiliser ESLint plutôt que de déterrer ce projet obsolète depuis longtemps.

C'est agréable de voir que la plupart des gens essaient de s'en éloigner maintenant, mais plus l'abandon est explicite, mieux c'est.

Je pense que ts-lint ne devrait plus être utilisé à la place d'eslint à partir de septembre 2020

Si votre projet utilise toujours ts-lint, envisagez d'utiliser
vérification https://github.com/typescript-eslint/tslint-to-eslint-config

mais typescript-eslint ne dit pas vraiment ce qui ne va pas https://github.com/typescript-eslint/typescript-eslint/blob/master/docs/getting-started/linting/FAQ.md#why -dont-i-see -typescript-errors-in-my-eslint-output

😢

mais typescript-eslint ne dit pas vraiment ce qui ne va pas https://github.com/typescript-eslint/typescript-eslint/blob/master/docs/getting-started/linting/FAQ.md#why -dont-i-see -typescript-errors-in-my-eslint-output

😢

Je pense que c'est plus ou moins vrai même pour TSLint et pourquoi même avec TSLint, nous appelons également tsc --noEmit dans nos scripts de lint.

J'ai généré une nouvelle application angulaire avec la version 8 et elle est livrée par défaut avec tslint. J'ai commencé à utiliser ts config pour l'implémentation husky. Ma question est la suivante: est-il obligatoire de passer à typescript-eslint comme recommandé étant donné que j'utiliserai Angular 8 dans mon projet pendant quelques années à venir?

@mayankkalbhor Comme vous l'avez vu, la valeur par défaut avec Angular est toujours d'utiliser TSLint. Je pense que ce sera jusqu'à Angular 11 ou plus tard jusqu'à ce que toutes les configurations par défaut dans Angular CLI soient configurées pour ESLint, voir la feuille de route : https://angular.io/guide/roadmap#migration -to-eslint.

Si vous avez déjà configuré quelque chose, vous devrez le migrer vous-même alors que rien ne vous oblige vraiment à utiliser ESLint au lieu de TSLint. C'est entièrement votre propre choix. Si vous préférez les fonctionnalités d'ESLint ou si vous prévoyez de passer du temps à configurer réellement vos règles, la migration est peut-être la solution pour vous. Cependant, si vous ne passez pas de temps à configurer vos règles TSLint et que vous en êtes satisfait, vous pouvez continuer à les utiliser indéfiniment. Ne vous attendez pas à des quantités indéfinies de corrections de bogues et à aucune mise à jour des fonctionnalités.

Je pense que le chemin par défaut pour les développeurs d'Angular est d'attendre qu'Angular inclue des scripts de migration dans une future mise à niveau d'Angular, probablement d'Angular 10 à 11 ou de 11 à 12.

N'importe qui est cependant libre de migrer vers ESLint par lui-même. Le seul véritable obstacle à votre migration est si vous avez le temps et que cela ne vous dérange pas de perdre les fonctionnalités actuellement absentes des configurations ESLint équivalentes. Là où il y a eu quelques configurations de peluchage via Codelyzer auparavant et nous avons maintenant un remplacement imminent ici : angular-eslint

Alors que nous atteignons la fin de vie du logiciel, ce serait génial si chaque document de règle avait un lien vers la règle de remplacement dans la documentation de typescript-eslint, tout comme le fait typescript-eslint à l'envers.

Cela signifie-t-il que je ne pourrai plus utiliser tslint dans mes projets après le 1er janvier 2021 ? Actuellement, mes builds utilisent tslint. Je ne vois aucune commande pour installer tslint sur le site Web npm. Et il dit que tslint est obsolète maintenant. Quelqu'un peut-il répondre à mes questions ?

Merci.

Vous pouvez l'utiliser, mais vous n'obtiendrez aucun type d'assistance.
Aussi plus de mises à jour.
Alors oui, vous devriez passer à eslint.

Lors de ma dernière vérification, tslint prend en charge plus de types de réparation automatique, je recommande donc d'exécuter 'tslint --fix' avant d'exécuter eslint.

Les choses ont peut-être changé entre-temps.

Je vais trier ce code ya