Tslint: Avertissement : La règle 'no-unused-variable' nécessite un message de vérification de type...

Veuillez remplir le modèle de problème. A quoi ressemble votre tslint.json ?

Je suis à la maison et j'ai essayé le même projet et ça marche bien. Je vais laisser cela ouvert jusqu'à ce que j'arrive au travail lundi pour tester à nouveau. Il faudra peut-être simplement réinstaller mes modules de nœud.

J'ai également mis à jour pour utiliser le modèle de problème.

Quelque temps après la mise à jour de tslint (peut-être v4 -> v5), les no-unused-variable ne sont pas disponibles sans les arguments --type-check , --project .

Cette option est difficile à utiliser et prend beaucoup de temps jusqu'à l'impression des résultats après la mise à jour, mais l'option de linting est importante et la plus utilisée. existe-t-il un moyen d'utiliser ces options sans arguments supérieurs ?

Quelque temps après la mise à jour de tslint (peut-être v4 -> v5), les variables no-unused ne sont pas disponibles sans les arguments --type-check, --project.

Je passe --project avec tslint --type-check --project tsconfig.json src/**/*.ts

Sur mon ordinateur personnel, je n'ai pas ce problème, mais sur mon ordinateur de travail, je le suis.

@everedifice il y avait des bugs avec l'implémentation de la règle, nous l'avons presque dépréciée (https://github.com/palantir/tslint/issues/1481), et avons finalement décidé de la conserver en déléguant à l'implémentation du compilateur de la variable no-unused (cela corrigeait la plupart des bugs). Il y a beaucoup de fils de discussion à ce sujet dans ce référentiel que je vous encourage à consulter, principalement liés au PR qui a apporté le changement décisif (

@mastrauckas Je ne peux pas vraiment vous aider sans plus de détails sur les différences entre vos deux environnements différents.

@adidahiya Je

En général:
ordinateur 1 : Windows 10 complètement à jour et pour le moment je ne reçois pas le error .
ordinateur 2 : macOS complètement mis à jour et j'obtiens le error .
ordinateur 3: Windows 7 complètement mis à jour et j'obtiens le error .

@everedifice Je viens de publier une nouvelle version de tslint-consistent-codestyle avec une nouvelle règle no-unused qui ressemble principalement à no-unused-variable avec quelques fonctionnalités supplémentaires mais sans avoir besoin d'utiliser --project --type-check .

Si vous êtes intéressé, vous pouvez trouver les documents ici : https://github.com/ajafff/tslint-consistent-codestyle/blob/master/docs/no-unused.md

L'ordinateur que je pensais ne pas avoir le problème semble avoir le problème après tout. Est-ce un bug ?

Du nouveau sur ce problème ?

J'ai le même problème.

Le même problème, mais avec les deux « Avertissement : la règle « pas de variable non utilisée » nécessite des informations de type. »
et « Avertissement : la règle « pas d'utilisation avant déclaration » nécessite des informations de type. » (Je peux voir que la faute de frappe dans 'information' a été corrigée entre les versions 5.5.0 et 5.7.0, mais c'est la seule chose qui a changé). Je l'exécute avec la version 2.4.1 dactylographiée. Des nouvelles de ce problème ?

Même problème ici

Ce problème est-il résolu ou un correctif temporaire pour arrêter d'afficher les avertissements.

Je ne pense pas que ce soit réglé. Je ne pense même pas qu'ils aient accepté comme problème.

Correctif permanent, utilisez no-unused-variable dans tsconfig.json au lieu de tslint.json. Si le compilateur peut fournir la même fonctionnalité, cela n'a aucun sens de le faire avec un linter.

@AnimaMundi eh bien, il fournit les mêmes fonctionnalités, mais lors de l'exécution de tslint dans le cadre de notre processus CI, celles-ci doivent être signalées pendant le test, pas pendant la construction. Je désapprouve que cela doive être ignoré/supprimé car le compilateur le fait au moment de la construction.

@haswalt Je ne vois aucune raison pour laquelle il doit être signalé pendant la phase de linting plutôt que la phase de construction. De toute façon, peu importe que vous soyez d'accord avec moi ou non, je n'ai rien à voir avec le développement de ce projet. Je viens de voir que quelqu'un cherchait un correctif et le lui a fourni.

Semblable au correctif de noUnusedLocals et noUnusedParameters dans mon tsconfig.json. Les erreurs s'affichent dans mon volet "problèmes".

@AnimaMundi @haswalt @keego les mérites d'une règle de lint par rapport à une vérification du compilateur pour les vars inutilisées ont été largement discutés dans d'autres threads TSLint (https://github.com/palantir/tslint/issues/1481 et threads liés) ; cette question n'est pas vraiment l'endroit pour elle.

@adidahiya mon commentaire visait simplement à partager un correctif pour ce problème, et non à commenter les mérites des règles de linter par rapport aux vérifications du compilateur.

S'en remettre au compilateur ne fait pas la même chose : le compilateur n'a qu'une seule option : FAIL.
La raison pour laquelle tslint le gère est qu'il doit souvent s'agir d'un avertissement (griffe verte vs rouge).

non seulement les problèmes de tslint peuvent être affichés comme des avertissements, mais ils peuvent également être ignorés de manière ponctuelle, alors que les erreurs de compilation tapuscrit ne peuvent pas être

Ces points ont déjà tous été hachés (voir mon dernier commentaire et les fils liés). Rien ne vous empêche d'utiliser no-unused-variable comme règle TSLint pour le moment. Je ne suis pas sûr de ce que ces commentaires de suivi essaient de réaliser.

@mastrauckas rencontrez-vous toujours des problèmes avec cette règle ? L'indicateur --type-check a été déprécié, mais --project est requis pour activer les règles basées sur la vérification de type.

A part : avec TS 2.6 , vous pouvez utiliser // @ts-ignore pour supprimer les erreurs du compilateur.

@adidahiya je répondais simplement aux commentaires ci-dessus qui prétendent qu'il n'y a aucune raison d'avoir cela comme règle de charpie plutôt que comme règle de compilateur.

mais vous avez raison, je suppose que le problème est lié à l'extension vscode et non à tslint lui-même. tbh il y avait tellement de problèmes sur ce sujet qu'il m'a fallu un certain temps pour comprendre exactement pourquoi cela ne fonctionne pas et où.

apprécier le pourboire. je vais def revenir à l'utilisation du paramètre du compilateur dès que nous passerons à 2.6

Un autre point pour ceux qui prétendent que cela ne devrait pas être une règle de charpie : les avertissements de charpie peuvent être réparables, et c'est un candidat de choix pour cela.

Je reçois le même avertissement dans le dernier code VS 1.19 The 'no-unused-variable' rule requires type information avec ceci (voir ci-dessous). Il manque quelque chose à ma configuration ?

{
  "extends": "tslint:recommended",
  "rules": {
    "linebreak-style": [true, "LF"],
    "quotemark": [true, "single", "avoid-escape", "avoid-template"],
    "no-console": false,
    "no-unused-expression": false,
    "ordered-imports": false,
    "member-access": [true, "no-public"],
    "object-literal-sort-keys": false,
    "curly": [true, "ignore-same-line"],
    "semicolon": [true, "never"],
    "no-var-requires": false,
    "no-unused-variable": true
  }
}

Si vous regardez le fichier readme de VSCode 1.19, il existe une nouvelle fonctionnalité permettant de considérer cette règle et d'autres comme des avertissements.
Pour nous, cela signifie :

• supprimer "no-unused-variable" de tslint.json
• ajoutez "noUnusedLocals" à nos tsconfig.json

Les autres règles sont laissées en exercice au lecteur ;-)

Notez que tslint est cette extension, tandis que tsconfig est le comportement intégré de VSCode.

J'ai choisi de supprimer no-unused-variable car VS 1.19 semble déjà les signaler.

Je ne comprends pas ce que VSCode a à voir avec cela. Il ne suffit pas que VSCode les traite comme des avertissements, j'ai besoin que la construction de mon serveur de développement webpack n'échoue pas à cause d'eux. Existe-t-il un remplacement pour no-unused-variable qui, indépendamment des éditeurs particuliers,

• être traité comme un avertissement pendant le développement
• Échec des builds pendant la CI

?

@pelotom , plusieurs personnes ont été redirigées ici depuis l'extension VSCode TSLint, par exemple depuis https://github.com/Microsoft/vscode-tslint/issues/219

Jusqu'à présent, TS n'était pas en mesure d'afficher certains problèmes sous forme d'avertissements (gribouillis verts), mais les peluches (ESlint, TSLint) le pouvaient. Nous nous demandions donc pourquoi TSlint ne signalerait pas les variables inutilisées en tant qu'avertissements. Mais à partir de la 1.19, le TS de VSCode peut faire ces avertissements et nous nous retirons de ce problème 😉

Pour être clair, j'utilise aussi VSCode et j'aimerais également voir ces avertissements mis en évidence dans l'éditeur, mais les paramètres de VSCode semblent être la mauvaise couche sur laquelle _configurer_ la gravité des erreurs du compilateur, car cela n'affecte pas le reste de votre chaîne d'outils.

Je suis d'accord avec toi Tom, et j'espère que la solution sera trouvée là où l'éditeur ainsi que nos procédures de build/CI auront le support approprié. Jusqu'à présent, nous avons assisté à une forte réticence (apparemment justifiée) et certains (dont moi) prendraient ce que nous pouvons, aujourd'hui, tout en gardant l'espoir d'une vraie solution.

Si vous regardez le fichier readme de VSCode 1.19, il existe une nouvelle fonctionnalité permettant de considérer cette règle et d'autres comme des avertissements.

@rnemec Je pense que vous vouliez écrire des "notes de version" au lieu de "lisez-moi". J'ai été assez stupide pour chercher le readme. Et pour tous ceux qui arrivent ici, autant citer le passage pertinent :

VS Code affiche désormais les problèmes de style de code TypeScript sous forme d'avertissements au lieu d'erreurs. Ceci s'applique à:

La variable est déclarée mais jamais utilisée
La propriété est déclarée mais sa valeur n'est jamais lue
Code inaccessible détecté
Étiquette inutilisée
Chute à travers le boîtier dans l'interrupteur
Tous les chemins de code ne renvoient pas de valeur
Les traiter comme des avertissements est cohérent avec d'autres outils, tels que TSLint. Ceux-ci seront toujours affichés comme des erreurs lorsque vous exécutez tsc à partir de la ligne de commande.

Vous pouvez désactiver ce comportement en définissant : "typescript.reportStyleChecksAsWarnings": false.

Il s'agit donc d'une solution temporaire et ne fonctionnerait que lors de l'utilisation de VSCode. Tout autre outil de construction utilisant directement tsc ne compilerait pas le code si les avertissements y sont laissés. J'ai des collègues qui utilisent Atom, ils ne pourront donc pas compiler le code si j'apporte des modifications et ignore l'un des avertissements. Droit?

Je ne comprends pas très bien comment cela résout quoi que ce soit. En quoi l'affichage de ces éléments sous forme d'avertissements est-il utile si le compilateur les traite toujours comme des erreurs ?

Et si je comprends bien, la solution à long terme serait soit d'ajouter un indicateur pour appliquer le même comportement dans tsc (le faire compiler avec des avertissements), soit de supprimer complètement ces vérifications du compilateur ?

--- Éditer ---
Je n'ai pas lu tous les commentaires précédents. @pelotom faisait déjà le même point.

Si vous souhaitez que les vérifications de charpie aient une gravité différente en mode dev par rapport au mode CI, vous pouvez le faire avec plusieurs configurations tslint.json où l'une extends l'autre. #2569 doit être corrigé pour que l'UX soit bon ici afin que vous puissiez basculer la gravité avec une seule ligne de configuration defaultSeverity - c'est en cours.

@adidahiya ce qui est discuté est un prétendu _remplacement_ de la règle de charpie no-unused-variable , en utilisant les tsc de noUnusedLocals .

@pelotom c'est vrai, j'ai compris -- mais je ne pense pas que tsc supporte encore un tel workflow. Vous pourriez avoir deux fichiers tsconfig.json où l'un étend l'autre et désactive chaque vérification de compilateur "non fatale" (dans ce cas, noUnusedLocals , noUnusedParameters ) individuellement, mais cela ne vous laisse pas voir les vérifications comme des avertissements dans votre éditeur.

@adidahiya oui, c'est pourquoi ce n'est pas un remplacement valide actuellement. Et je préférerais de loin que no-unused-variable fonctionne correctement dans VSCode plutôt que d'investir plus d'efforts pour que noUnusedLocals se comporte davantage comme une règle de charpie. OMI, c'était une erreur pour le compilateur d'essayer de s'approprier ce type de contrôle en premier lieu.

Et je préférerais de loin que no-unused-variable fonctionne correctement dans VSCode plutôt que d'investir plus d'efforts pour que noUnusedLocals se comporte davantage comme une règle de peluche.

Logique. Je crois que ce projet vise à le faire : https://github.com/angelozerr/tslint-language-service. Vous pouvez utiliser des règles qui nécessitent une vérification de type avec ce plugin.

J'ai parlé trop tôt. Nous sommes bloqués sur https://github.com/palantir/tslint/issues/2649 pour que ce plugin soit utile. Suivez plutôt ce problème.

@adidahiya oui , je le suis depuis un certain temps.

des nouvelles à ce sujet? Sera-t-il obsolète ou non ?

@philip-firstorder en utilisant ceci a résolu le problème pour moi --project tsconfig.json

tslint -c tslint.json --project tsconfig.json src/**/*.ts

no-unused-variable est maintenant obsolète, voir #3918 et #3919

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

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