web-dev-qa-db-fra.com

Quelle est la différence entre `extend` et` rulesDirectory` dans TSLint

Le fichier de configuration TSLint.json ( https://github.com/palantir/tslint ) prend en charge extends et un tableau rulesDirectory comme ceci

{
  "extends": [
    "tslint-Microsoft-contrib",
    "tslint-config-security"
  ],
  "rulesDirectory": [
    "node_modules/tslint-eslint-rules/dist/rules",
    "node_modules/tslint-Microsoft-contrib",
    "node_modules/tslint-config-security"
  ]
}

Les documents semblent légèrement ouverts à l'interprétation pour les nouveaux utilisateurs qui ne connaissent pas l'outil.

J'apprécierais que quelqu'un puisse clarifier quelques points sur le comportement de extends et rulesDirectory par rapport à l'utilisation dans l'éditeur de code VS et tslinting en général.

  1. extends uniquement fournit-il une configuration par défaut (si fournie par le package)?

  2. et est-ce donc différent de rulesDirectory?

    • rulesDirectory fournit-il uniquement des règles vous permettant de vous inscrire spécifiquement (et est requis si vous spécifiez des règles dans la racine tslint.json)?

    • Dois-je quand même spécifier les packages tslint dans les deux extends etrulesDirectory?

  3. En supposant que extends fournit les valeurs par défaut d'un autre fichier de configuration tslint, pourrais-je spécifier le rulesDirectory et ajouter une règle pour remplacer un indicateur spécifique?

Préoccupé car seules certaines des règles apparaissent dans la saisie semi-automatique IntelliSense et quelques comportements pour lesquels j'apprécierais plus de clarté.

11
mittens pair

Quelle est la différence entre extends et rulesDirectory dans TSLint

Ils sont très différents.

  • extends vous permet d'appliquer une configuration tslint existante puis de l'étendre
  • rulesDirectory vous permet simplement d'ajouter des répertoires pour des règles personnalisées.
5
basarat

? Réponse tirée de documentation de configuration tslint au 6 avril 2018 :

  • extends?: string | string[]: Le nom d'un préréglage de configuration intégré (voir les préréglages intégrés ci-dessous), ou un chemin ou un tableau de chemins vers d'autres fichiers de configuration qui sont étendus par cette configuration. Cette valeur est gérée à l'aide de la sémantique de résolution du module de nœud. Par exemple, une valeur de "tslint-config" dirait à TSLint d'essayer de charger le fichier principal d'un module nommé "tslint-config" en tant que fichier de configuration. Des fichiers spécifiques à l'intérieur des modules de nœuds peuvent également être spécifiés, par exemple. "tslint-config/path/to/submodule". Les chemins relatifs vers les fichiers JSON ou les modules JS sont également pris en charge, par ex. "./tslint-config".
  • rulesDirectory?: string | string[]: Un chemin vers un répertoire ou un tableau de chemins vers des répertoires de [règles personnalisées] [2]. Ces valeurs sont gérées à l'aide de la sémantique de résolution du module de noeud, si un index.js est placé dans votre répertoire de règles. Nous préférons utiliser des chemins relatifs ou absolus, si le module ne peut pas être résolu. Si vous voulez éviter la résolution du module, vous pouvez directement utiliser un chemin relatif ou absolu (par exemple avec ./).

Toutes les règles spécifiées dans ce bloc rules remplaceront celles configurées dans toute configuration de base en cours d'extension.

1
mittens pair

Jetez un œil à docs .

La principale différence semble être:

  • "extends" utilise des ensembles de règles intégrées

  • "rulesDirectory" utilise des règles personnalisées (vos propres règles, pas intégrées)

0
WebBrother