Tslint: Demande de fonctionnalité : autoriser l'exclusion de fichiers pour une règle spécifique

Pourquoi n'utilisez-vous pas simplement :

/* tslint:disable:class-name */
// your generated file here

Cela ne fonctionne-t-il pas ?

Cela pourrait en effet être utilisé pour le faire fonctionner, mais j'ai déposé cette demande de fonctionnalité afin d'éviter de modifier le générateur TypeScript (ou d'ajouter de la complexité au processus de génération, en ajoutant des fichiers générés avec des astuces tslint).
L'utilisation de caractères génériques pourrait également être bénéfique pour appliquer de manière déclarative certaines règles uniquement à des types de sources spécifiques (main/unitTests/e2eTests) à partir de la configuration de tslint, et non à partir de chaque fichier individuellement.

Qu'est-ce que tu penses?

Si vous ne voulez pas mettre de commentaires dans le fichier, ne transmettez tout simplement pas le fichier à tslint pour le linting, non ?

Il semble trop lourd d'ajouter d'autres options ailleurs lorsqu'il existe au moins deux moyens d'obtenir l'exclusion (partielle) des fichiers

Si vous ne voulez pas mettre de commentaires dans le fichier, ne transmettez tout simplement pas le fichier à tslint pour le linting, non ?

C'est exactement ce que j'ai fait, mais maintenant aucune des règles n'est vérifiée par rapport aux fichiers exclus.

Il semble trop lourd d'ajouter d'autres options ailleurs lorsqu'il existe au moins deux moyens d'obtenir l'exclusion (partielle) des fichiers

Ouais, c'est ce que j'avais prévu comme réponse ;) J'avais aussi quelques doutes - du moins sur la mise en œuvre (que j'ai essayé de garder aussi simple que possible).

En réalité, si cela devait être implémenté, il serait avantageux que vous puissiez définir des constantes pour les modèles d'inclusion et d'exclusion, afin que vous n'ayez pas à copier-coller le même modèle d'inclusion/exclusion dans toutes les règles où vous souhaitez filtrer les mêmes fichiers... J'ai pensé qu'il n'était peut-être pas raisonnable de rendre l'exemple plus compliqué, mais j'avais quelque chose comme ça en tête :

{
    "constants": {
        "generatedFilesGlob": "**/generated.ts",
        "someOtherConstant": "some other value, that could be reused",
        ...
    },
    "rules": {
        "class-name": true,
        "some-otherrule": [ true, "arg1", "arg2", "arg3"],
        "rule-with-exclude": [ {"exclude": "generatedFilesGlob"}, "arg1", "arg2", "arg3"],
        ...
    }
}

mais cela rendrait le fichier de configuration plus difficile à analyser. Cela m'a amené à penser à la prise en charge des fichiers js pour la configuration, en plus des fichiers json. Par exemple:

const generatedFilesGlob = "**/generated.ts";
const allExceptGenerated = {exclude: generatedFilesGlob};
module.exports = {
    "rules": {
        "class-name": true,
        "some-otherrule": [ true, "arg1", "arg2", "arg3"],
        "rule-with-exclude": [ allExceptGenerated , "arg1", "arg2", "arg3"],
        "another-rule-with-the-same-exclude-pattern": [ allExceptGenerated , "arg1", "arg2", "arg3"],
        ...
    }
}

L'utilisation de fichiers JavaScript avec des modules (comme le fait gulp) a un autre avantage - elle permet de commenter et n'est pas si stricte sur les virgules après le dernier élément du tableau ou la propriété de l'objet.

@atsu85 problème intéressant, mais comme @myitcv l'a indiqué, je suis réticent à introduire des listes de fichiers / globs dans tslint.json raison de la complexité / encombrement supplémentaire dans le fichier de configuration. Je suis d'accord pour que TSLint accepte les fichiers .js pour la configuration en plus des fichiers .json . Je pense que cela vous aiderait à résoudre le cas d'utilisation - vous pouvez configurer deux tâches de construction tslint (une pour vos sources habituelles, une pour les sources générées) et désactiver par programme la règle class-name en une d'entre eux dans le même fichier tslintConfig.js .

Classé #1065 pour la prise en charge des fichiers de configuration .js

Très bien, je vais fermer ce problème en faveur des fichiers de configuration js uniquement

J'ai un cas d'utilisation pour cela qui pourrait avoir du sens. J'ai des fichiers de test (*.spec.ts) avec lesquels je souhaite partager la plupart de mes règles Typescript TSLint, car les bonnes pratiques de codage s'appliquent également à mes tests.

Cependant, je teste quelques constantes qui sont configurées pour la règle des "nombres magiques", afin de ne pas avoir 5 dans mon code :
(Foo.substr(0,5);
mais assurez-vous que c'est un const
(Foo.substr(0,CONSTANT.FIVE);

En tant que tel, mon cas de test pour mon const qui est inclus à partir d'un fichier commun, a un test pour s'assurer que le const FIVE = 5 est toujours défini. Le test alors expect(CONSTANTS.FIVE).toBe(5); échoue à la vérification TSLint puisque le nombre magique est utilisé dans le test. Bien que je ne teste pas toutes les constantes de cette façon, je souhaite vérifier ces paramètres numériques pour m'assurer qu'ils ne changent pas car ils devraient conserver la taille spécifique.

Je pourrais utiliser deux configurations TSLint différentes, mais je veux vraiment éviter qu'elles ne se désynchronisent ou, lors de l'ajout d'une nouvelle règle, d'avoir à le faire à plusieurs endroits.

Je peux faire le /* tslint:disable :no-magic-numbers*/ pour le seul fichier pour ces tests spécifiques qui fonctionne pour moi, mais peut-être que dans d'autres cas dans le fichier de tests, une règle commune devra peut-être être une exception, et au lieu de mettre à jour chaque *.spec.ts, le modèle global de la règle fonctionnerait-il ?

J'ai le même cas d'utilisation que @Chowarmaan.

J'ai des fichiers de test *.test.ts dans lesquels j'utilise des dépendances de développement, par exemple enzyme .
Dans tslint.json règle no-implicit-dependencies activée et je souhaite désactiver cette règle uniquement pour *.test.ts . Ces fichiers de test ne sont pas tous dans le même dossier donc je dois maintenant mettre :

/* tslint:disable:no-implicit-dependencies */

au début sur chaque fichier test ce qui est embêtant

C'est un problème similaire que je rencontre ainsi que @RomanGotsiy où vous pouvez ajouter des désactivations en haut des fichiers de test, mais cela devient encombrant pour chaque fichier. Les fichiers d'exclusion seraient utiles car vous pourriez exclure des règles pour certains fichiers de signatures (fichiers de test, *.spec.ts) et disposer d'un fichier de configuration propre qui vous permet également d'activer simplement plus de règles selon vos besoins et d'autoriser vos tests. de les utiliser aussi. Peut-être que la liste des fichiers à exclure inclurait alors simplement les règles que vous souhaitez désactiver, au lieu d'ajouter l'exclusion de fichiers à chaque règle ?

Cette. 100%. Avoir ce problème avec un monorepo où les dépendances de test sont répertoriées dans l'espace de travail, donc tslint pleure à propos de no-implicit-dependencies . Cela doit être fait avec un seul fichier de configuration pour que le linting IDE fonctionne toujours

Je pense que ce problème est également lié à #3447

Je vais également compléter ce fil obsolète. Je suis en train de mettre en œuvre un magasin NgRx dans mon projet Angular. La version AOT me crie dessus lorsque j'exporte une référence const vers une fonction ...

export const reducer = ( state = initialState, action: CurrentAction): CurrentState => {...}

Me donnant une erreur Function expressions are not supported in decorators in 'reducers' . Le problème vient de nos règles de peluchage. Nous avons spécifiquement activé la règle only-arrow-functions dans tout le projet... ce serait merveilleux d'ajouter une correspondance de modèle sur l'exclusion pour dire exclure les fichiers de *.reducer.ts comme exemple pour cette règle spécifique, mais autorisez il doit rester intact pour tous les autres fichiers.

Dans l'état actuel des choses, l'ajout de cette ligne en haut du fichier pour chaque fichier de réduction est fastidieux. Il semble juste qu'il devrait y avoir un meilleur moyen.

Necrobumping ça aussi. J'essaie d'ajouter tslint-microsoft-contrib à un projet Vue et un tas de ses règles bombardent les fichiers .vue; cela pourrait être une solution de contournement utile pour des problèmes comme celui-ci avant que les auteurs de règles ne se mettent à aplanir ces bogues - s'ils le souhaitent un jour. Dans l'état actuel des choses, ajouter un commentaire pour désactiver un tas de règles dans absolument tous les fichiers Vue que j'écris est en effet fastidieux. Il est également logique d'être un peu moins strict dans le code de l'interface utilisateur ou de traiter les idiomes du framework, par exemple l'utilisation des exportations par défaut