Tslint: no-unused-variable TypeError : Impossible de lire la propriété '1' de null

Bonne trouvaille @hotforfeature. J'ai commencé à aborder ce sujet sur https://github.com/palantir/tslint/pull/3919 car cela était lié à certains changements à venir dans TS 2.9 qui ne feront qu'exacerber ce problème.

Mon PR empêche la levée d'une exception, cependant, il ignore simplement ignorePattern dans les cas que vous avez mentionnés, ce qui n'est pas génial. Je pense que nous devrons ajouter un code complexe, un peu comme ce que nous faisons actuellement pour les corrections automatiques d'importation :/

Je me demande si nous devrions penser à déprécier cette règle. tsc fournit désormais un moyen d'ignorer ses avertissements et prend en charge les correctifs automatiques pour ses avertissements via un IDE.

Autant que je sache, le principal avantage de cette règle est ignore-pattern , mais il est difficile de l'implémenter correctement de la manière dont la règle est maintenant écrite pour dépendre des diagnostics tsc. TSLint est également un peu plus flexible que tsc en ce qui concerne la désactivation des règles dans certains fichiers. @suchanlee des réflexions sur tout cela? Je sais que vous avez corrigé cette règle récemment

Mon cas d'utilisation principal pour cette règle est de résoudre automatiquement les problèmes de commit dans un hook git lors du linting. Je pense donc toujours qu'il y a une grande valeur ici même si tsc propose quelque chose via des intégrations IDE.

@JKillian, je pense que la règle commence à devenir de plus en plus chère à prendre en charge avec la prise en charge par TSLint de plusieurs versions de Typescript et des changements continus dans le comportement de Typescript. Et puisque Typescript prend en charge la fonctionnalité, nous devrions nous pencher vers cette fonctionnalité. Mais comme les versions antérieures de TS ne le prennent pas en charge, je ne pense pas que nous devrions le supprimer. Cependant, je pense que nous devrions commencer à penser à déprécier la règle et à travailler avec les gens de TS pour mieux prendre en charge les flux de travail TSLint actuels avec TS.

Je soutiendrais la proposition de

@hotforfeature - reconnaissez votre cas d'utilisation et trouvez-le raisonnable. Cependant, en raison de la complexité de la règle, je pense que nous allons la déprécier (voir #3919).

Comme toujours, tout le monde est invité à copier le code source de la règle et à le déplacer vers un package externe et à continuer à l'utiliser/l'améliorer de cette façon !

Pour ce que ça vaut :

{
  "compilerOptions":  {
    "noUnusedLocals": true,
    "noUnusedParameters": true,
  }
}

L'utilisation de ce qui précède dans tsconfig permet de désactiver la règle de lint no-unused-variable .

no-unused-variable est maintenant obsolète, et le compilerOptions ci-dessus est maintenant la solution officielle.

Définir noUnusedLocals et noUnusedParameters dans compilerOptions n'est pas tout à fait la même chose que le no-unused-variable de tslint. À partir de maintenant, les vars inutilisées plantent la version ou restent inaperçues et il n'y a plus de mode d'avertissement 😞

@giladgray , @killtheliterate a écrit :

L'utilisation de ce qui précède dans tsconfig permet de désactiver la règle de lint sans variable inutilisée.

Je ne veux pas désactiver cette règle, car comme l' a écrit

Définir noUnusedLocals et noUnusedParameters dans compilerOptions n'est pas tout à fait la même chose que no-unused-variable tslint

Mon cas d'utilisation est le code généré. Je veux que mon code écrit manuellement suive cette règle, mais pour éviter de rendre le générateur de code extrêmement complexe, j'aimerais désactiver cette règle dans le code généré (ou au moins dans certaines sections du code généré) - c'est smth that can' à faire avec les options du compilateur TypeScript 😞

À tout le moins, cette dépréciation devrait être documentée sur le site Web de TSLint , mais je suis tout à fait d'accord pour dire que cette dépréciation était prématurée. Avez-vous l'intention de reconsidérer? Une contribution communautaire serait-elle acceptée?

Cette dépréciation est ridicule. Les drapeaux du compilateur sont un remplacement TERRIBLE. Ils cassent la construction et ne se réparent pas. En quoi est-ce une solution raisonnable à orienter vers les gens ? Si l'option ignore-pattern est trop difficile à faire fonctionner maintenant, désapprouvez-la à la place.

les gens - il suffit de lier ceci à https://github.com/palantir/tslint/issues/4232. Il est bien compris et convenu que les options de compilation intégrées ne sont _pas_ un remplacement suffisant pour no-unused-variable . L'implémentation originale de la règle ne fonctionnait pas bien avec les autres outils TS et a dû être désactivée. #4232 pistes trouvant un moyen de le réactiver.

En attendant, vous pouvez utiliser quelque chose comme tsc --noEmit --noUnusedLocals --noUnusedParameters comme outil séparé pour utiliser les vérifications intégrées. Oui, ce n'est pas aussi bon qu'un no-unused-variables configurable.

continuer la discussion dans #4100 & #4232