Tslint: Fonctionnalité : fichier ".tslintignore" pour exclure les globs

bonne suggestion. nous allons l'examiner.

+1

Pour TSD, je voudrais générer ceci dans le dossier de saisie des utilisateurs lors de l'initialisation d'un nouveau projet.

+1

Ceci est nécessaire pour traiter les erreurs de peluche comme un blocage. Je veux que mon code soit linté, pas le code du fournisseur.

+1

+1

+1 C'est exactement la solution dont nous avons besoin. Nous obtenons un certain nombre d'erreurs tslint sur les fichiers d.ts. Pouvoir exclure à la fois des dossiers et des fichiers spécifiques sera très important car nous ne voulons pas non plus pelucher du code que nous n'avons pas écrit.

Je suis prêt à essayer mais je ne sais pas où le mettre. Voulons-nous que ce soit une fonctionnalité cli ou voulons-nous également prendre en charge cela dans la bibliothèque ?
Si dans la bibliothèque, c'est un peu bizarre parce que la méthode lint () renvoie un objet de résultat, nous devons donc renvoyer un objet de résultat vide et factice.
Voir ici pour un travail en cours, mais oui, je ne suis pas sûr des éléments ci-dessus.
https://github.com/DickvdBrink/tslint/compare/palantir :master...Di ckvdBrink:ignoreFile

Nous utilisons Visual Studio et les outils Web Essentials. Pour nous, le flux de travail idéal serait de spécifier un fichier .tjshintignore qui contiendrait quelque chose comme typings\ qui ignorerait tous les fichiers d.ts de ce dossier. Je ne sais pas exactement si Web Essentials utilise la fonctionnalité cli ou la bibliothèque, il m'est donc difficile de le savoir. Je suis en fait maintenant un peu confus, car j'ai trouvé ce fil qui semble indiquer qu'une solution pour cela existe peut-être déjà? https://github.com/madskristensen/WebEssentials2013/issues/617

Je pense qu'ils utilisent cli.
https://github.com/madskristensen/WebEssentials2013/blob/aaa83c3f6f7c9b051d7ef34be8498c6b67f37fca/EditorExtensions/TypeScript/Linters/TsLintCompiler.cs

Je pense qu'il est fermé car quelqu'un a créé ce problème, voir les citations ci-dessous :

Would you like to send them a feature request?
I see somebody already has. Thanks :-)

Ah, c'est logique. Mal lu ça.

Je pense que l'implémenter via la CLI est bien pour l'instant. les personnes utilisant grunt-tslint peuvent déjà exclure des fichiers via les globbers de fichiers/répertoires de grunt.

Nous envisageons également une exclusion globale pour tous les services basés sur des nœuds dans Web Essentials : https://github.com/madskristensen/WebEssentials2013/issues/589. Néanmoins, avoir cette caractéristique dans tslint a sa propre signification.

Mise à jour : dans Web-essentials, la fonctionnalité est livrée avec la version nocturne v2.2.4.

des mises à jour à ce sujet ?

Cela semble être une caractéristique relativement importante qui devrait être priorisée. Voulait noter l'intérêt pour cette fonctionnalité à partir d'une question SO .

Je ne pense pas particulièrement qu'un fichier .tslintignore soit nécessaire, je préfère l'idée plus simple d'ajouter une option CLI --exclude .

Il serait peut-être préférable de prendre en charge cela via tsconfig.json (# 858) plutôt que de le réimplémenter dans un indicateur CLI ...

Hmm, la difficulté avec cela est que vous voudrez peut-être compiler des fichiers différents de ceux que vous avez créés. Donc, je pourrais potentiellement utiliser tsconfig.json puis utiliser --exclude pour ne pas pelucher quelques-uns des fichiers normalement inclus.

Contrairement à CLI, cela ne serait-il pas un ajustement naturel dans le fichier tslint.json, puis ajouterait un contrôle d'ignorance qui analyse les "ignorePaths" à https://github.com/palantir/tslint/blob/master/src/tslint .ts#L46 ?

+1

+1, un .tslintignore sera super

+1 pour .tslintignore ou ajouter une option pour ignorer certains chemins dans tsconfig.json
Cela pourrait être similaire à https://github.com/bbatsov/rubocop#inclusiveexcling -files

Avez-vous besoin d'aide pour sa mise en œuvre ?

Dans un premier temps, nous allons bientôt fusionner #1006, ce qui ajoute une simple option CLI --exclude . Cela vous amène-t-il la plupart du temps? Si vous utilisez des outils supplémentaires en plus de tslint , il a probablement un support glob/exclure (grunt/gulp/etc). Quelle est l'importance de cette prise en charge dans tslint.json ?

Je n'appelle plus tslint à partir des scripts NPM, mais cela peut être important pour ceux qui le font puisque NPM ne fournit pas (et je crois qu'il ne le fera jamais) un support global multiplateforme.

Je ne pense pas que ce soit une bonne idée d'ajouter des options pour les fichiers que vous voulez ou ne voulez pas pelucher dans le fichier tslint.json . Il ne semble tout simplement pas que ça rentre là-bas. Cela n'est pas non plus cohérent avec la configuration de jshint . Oui, ce sont deux outils différents mais ils font pratiquement la même chose. Étant donné que TS est un super ensemble de JS, il devrait y avoir une certaine cohérence entre les deux. Je préférerais avoir un fichier .tslintignore (tout comme .jshintignore ) pour maintenir la cohérence entre JS et TS. Gardez-le séparé de tsconfig.json puisque lint ne compile pas.

+1 pour l'option CLI, c'est un bon début.

Je voulais mentionner que # 1006 a fusionné et était dans une version il y a environ un mois, donc si vous utilisez la dernière version de la CLI TSLint, vous aurez un indicateur exclude disponible pour utilisation.

+1

+1

+1

qu'est-ce que les gens font +1 ici ? un indicateur --exclude est disponible dans la CLI depuis la v3.6 qui vous permet d'exclure les globs (fichiers, chemins, peu importe).

@adidahiya Cela n'aide pas avec WebStorm, par exemple. Il n'y a pas d'option pour spécifier des drapeaux.

Je comprends que cela devrait être une demande de fonctionnalité pour les développeurs WebStorm, mais il semble que ce soit super facile à implémenter du côté de ts-lint. Et cela est fait pour les autres bibliothèques de peluches par défaut. Alors pourquoi ne pas en faire ainsi ?

@fyodorvi cool, j'ai mis à jour le titre et la description du problème. Nous voudrions probablement résoudre le chemin du fichier .tslintignore de la même manière que nous résolvons tslint.json .

Avantages / inconvénients d'un nouveau fichier par rapport à en faire un nouveau champ dans tslint.json ?

Il existe une solution de contournement pour ceux qui souhaitent utiliser tslint avec WebStorm :
Vous pouvez mettre un fichier vide (avec '{}' à l'intérieur) tslint.json dans votre dossier node_modules et activer l'option 'Rechercher tslint.json' dans WS. Cela réinitialisera complètement toutes les règles de tslint pour le dossier node_modules, et il sera silencieux sur le code du fournisseur (ou vous pouvez ajouter des règles spécifiques ici si vous le souhaitez)

J'ai suivi ce fil pour pouvoir exclure des fichiers utilisant spécifiquement vscode (depuis avant que le nom ne soit changé pour être spécifique à .tslintignore). Je voulais faire savoir aux autres qui essaient d'intégrer l'exclusion avec vscode qu'il existe un problème distinct et une PR récente pour les exclusions tslint spécifiques à vscode.

@adidahiya un champ avec un tableau de répertoires ou de fichiers à l'intérieur de tslint.json devrait suffire, je préférerais ne pas m'inquiéter d'un autre fichier pour contrôler cette entreprise alors que nous avons déjà un fichier de configuration défini dans un projet.

@Karabur votre solution de contournement ne fonctionne pas pour moi, j'ai même essayé d'ajouter un objet de règles vide, ai-je raté quelque chose ?

Un seul fichier suffit. Cela correspondrait également au fonctionnement de tsconfig,json.

Une option exclude dans tslint.json serait bien (un seul fichier à utiliser de cette façon) et c'est le nom de la section glob ignore de tsconfig.json comme bien (oui tsconfig.json inclure / exclure prend désormais en charge les globs dans TypeScript plus tard)

Quelqu'un sait-il ce que fait Eslint, car je suis sûr qu'il l'aurait également fait? :Rose:

À l'heure actuelle, tslint.json n'a aucun contrôle sur _ce_ qui est pelucheux, il contrôle uniquement _comment_ les fichiers sont pelucheux. En fait, selon la façon dont vous configurez les choses, la CLI TSLint peut en fait pelucher différents fichiers selon différentes règles dans la même exécution.

Je ne suis pas contre une option exclude dans tslint.json , mais cela pourrait finir par être un léger changement de paradigme et devrait être mûrement réfléchi.

PS Toujours heureux d'entendre vos commentaires @basarat , je viens de lire votre gitbook TS aujourd'hui 😉

Je viens de sortir une nouvelle version d' alm avec tslint intégré à la version 0.3.0 :heart:

Après l'avoir assis dans mon cerveau, voici le résumé de la conception avec laquelle j'ai opté pour l'intégration IDE et qui semble fonctionner à merveille:

• tous les fichiers dans le tsconfig.json actuel sont lintés sauf les fichiers .d.ts
• tslint.json doit être déterminé en utilisant un findup partir de tsconfig.json .

Je l'ai également documenté ici : https://basarat.gitbooks.io/alm/content/features/lint.html N'hésitez pas à utiliser les idées/source pour toute autre intégration IDE :rose:

@basarat Je pense que ces choix semblent parfaits ! Je n'ai pas encore essayé, mais je vais devoir essayer très bientôt 💻

Veuillez arrêter de publier des commentaires +1 et utiliser la fonction de vote intégrée Github sur la description originale du problème. Je vais supprimer vos commentaires +1 maintenant.

Trois ans se sont écoulés, et ce n'est toujours pas mis en œuvre ? Comment se fait-il, c'est l'une des caractéristiques les plus triviales et les plus importantes de l'OMI.

Trois ans se sont écoulés, et ce n'est toujours pas mis en œuvre ? Comment se fait-il, c'est l'une des caractéristiques les plus triviales et les plus importantes de l'OMI.

C'est de l'OSS après tout : si vous le voulez, soumettez un PR.

Le problème actuel pour moi est :

--exclude {node_modules,.git,cache}

L'opérateur {} ne fonctionne pas et je ne vois aucun moyen d'exclure différents répertoires...

@monolithe :

--exclude node_modules --exclude .git --exclude cache

tu devrais faire ce que tu veux

Trois ans se sont écoulés, et ce n'est toujours pas mis en œuvre ? Comment se fait-il, c'est l'une des caractéristiques les plus triviales et les plus importantes de l'OMI.

C'est de l'OSS après tout : si vous le voulez, soumettez un PR.

J'ai soumis un PR : https://github.com/palantir/tslint/issues/2409

@abenhamdine des idées à qui je devrais demander d'examiner ?

Cogner un problème vieux de 3 ans et plus recherché par des centaines de personnes, avec un PR fonctionnel soumis, mais aucune action pendant six mois.

Merci pour la bosse. Notez que le PR lié, #2409, concerne une nouvelle option de configuration dans tslint.json , qui n'est pas tout à fait la même que le problème d'origine (fichier .tslintignore ). C'est un pas dans la bonne direction cependant; J'ai laissé d'autres commentaires CR.

+1
Option :

• Fichier .tslintignore dans le dossier à ignorer.
• Fichier tslint.json (fichier global) nouvelle propriété exclude avec une liste de chemins/dossiers.
  Ce serait bien.

Soit dit en passant, la fonctionnalité a été publiée en [email protected]

Droit. Exemple:
Créez un dossier dans votre projet avec le nom .vscode et un fichier à l'intérieur settings.json .

{
  "tslint.exclude": "**/app/models/**"
}

pour ignorer tous les fichiers dans /app/models/. N'hésitez pas à améliorer l'expression. :)

+1

+1
besoin .tslintignore

Oh hé, cela devrait maintenant être pris en charge par linterOptions . Selon https://palantir.github.io/tslint/usage/configuration/ :

• linterOptions?: { exclude?: string[] } :
  
  
  
  • exclude: string[] : Un tableau de globs. Tout fichier correspondant à ces globs ne sera pas linté. Tous les modèles d'exclusion sont relatifs au fichier de configuration dans lequel ils ont été spécifiés.
  
  

Est-ce que cela fonctionne assez bien pour tout le monde ? Y a-t-il autre chose qu'un .tslintignore devrait faire ?

/cc @am11 , @basarat

Salut @JoshuaKGoldberg , c'est un bon début. Je pense que ce que beaucoup de gens sur ce fil espéraient d'un fichier .tslintignore en plus de la fonctionnalité, c'est qu'il serait conforme à la norme déjà établie par git, npm, eslint, etc. Les gens aiment cette norme, se sentent très à l'aise avec lui, et je m'y attendais en quelque sorte - par exemple, j'ai trouvé ce problème lorsque j'ai créé un fichier .tslintignore en supposant que cela fonctionnerait, et j'ai été surpris (à tort ou à raison) quand ce n'était pas le cas.

Hmm. Je doute d'avoir deux normes sur la façon dont cela devrait fonctionner. Si vous avez à la fois .tslintignore et linterOptions.exclude dans un répertoire, comment le comportement fonctionne-t-il ?

Edit : oh, et TypeScript rompt également la tendance .*ignore avec son tsconfig.json .

eslint et stylelint prennent tous deux en charge un indicateur CLI --ignore-path ou une option JS ignorePath . Pourquoi tslint pas?
Veuillez ajouter un support pour cela ! :prier:

Étant donné # 4534 et la solution de contournement linterOptions.exclude , cela semble hors de portée pour TSLint maintenant. L'approche recommandée est de migrer vers typescript-eslint ; si vous devez exclure certains fichiers TypeScript du peluchage TSLint, utilisez linterOptions.exclude . Fermeture de ce sujet pour entretien ménager.

S'il y a un bloqueur dans linterOptions.exclude qui rend la migration plus difficile, veuillez signaler un nouveau problème pour signaler le bogue !

🤖 Bip boop ! 👉 TSLint est obsolète 👈 et vous devriez passer à typescript-eslint ! 🤖

🔒 Ce problème est verrouillé pour éviter d'autres discussions inutiles. Merci! 👋