tslint folders Download - tslint folders Téléchargement du code source

tslint folders

Autres catégories

v4.1.5

Télécharger

? tslint-repliants

Utilisez Tslint pour vérifier les importations non valides entre les packages et les dossiers de votre projet TypeScript.

Validation et documentation automatique de l'architecture des packages (via tslint-folders-diagrams ).

statut - stable

Tslint-Folders est stable et utilisé tous les jours dans les versions CI et sur les boîtes de développement (Linux, Mac, Windows) pour au moins un produit majeur.

pourquoi ?

Économisez du temps passé manuellement à réviser les erreurs «idiotes» telles que:

Violations de l'architecture:
- Importation d'un package ou d'un dossier de «niveau supérieur»
- importation à partir de dossiers dans les deux sens
Importation d'un dossier «non valide» comme «DIST» ou «modules» (laid, et dans certains cas, cela peut entraîner des problèmes tels que WebPack regroupant le même code deux fois)
Pousser le code avec des tests désactivés ou avec du code de point d'arrêt
La dénomination incohérente des fichiers (le file-name-casing de règle Tslint par défaut permet uniquement un style)

caractéristiques

Utilise un fichier JSON simple pour modéliser les relations souhaitées entre les dossiers et les sous-repliants
Fournit une règle TSLINT personnalisée qui marche sur votre projet TypeScript, en vérifiant les importations qui violent le modèle
Autres règles personnalisées:
- détecter configurablement les tests désactivés
- détecter le code de débogage / point d'arrêt
- détecter les importations non valides à partir de dossiers comme «node_modules» ou «dist»
- détecter les noms de fichiers qui ne correspondent pas au style attendu (permet plus d'un style de nom de fichier)
Fournit un outil pour générer des diagrammes d'architecture à partir du même modèle, via des diagrammes Tslint-Folders

versioning

Nous utilisons Semver pour le versioning. Pour les versions disponibles, voir les versions.

usage

1 Installer via le fil dans votre site Web

 yarn add tslint-folders

2 Configurez Tslint pour ramasser les règles personnalisées

Modifiez votre tslint.json pour avoir une entrée "rulesDirectory" qui pointe vers Tslint-Folders.

Normalement, ce serait comme:

  "rulesDirectory": "./node_modules/tslint-folders/dist/lib/"

Voir tslint.tslint-folders.json pour un exemple.

3 Configurez les règles

Les règles Tslint sont activées et configurées dans tslint.json .

Voir la section sous tsf-folders-imports-between-packages dans Tslint.tslint-Folders.json ou les tests unitaires pour des exemples.

Facultativement, vous pouvez diviser la configuration Tslint-Folders en un fichier séparé, comme tslint.tslint-folders.json . Pour référencer le fichier, ajoutez ce code à tslint.json :

  "extends": "./tslint.tslint-folders.json"

En supposant que Tslint est déjà en place, vous devriez maintenant voir que toutes les importations inattendues (ou tests désactivées) sont signalées par Tslint. Cela devrait fonctionner comme d'habitude pour Tslint: sur la ligne de commande, ou dans un éditeur tel que Visual Code (peut nécessiter de rafraîchir l'éditeur).

4 générer un résumé de la configuration du package

Voir Tslint-Folders-Diagrams

Utilisation de Graphviz pour générer des diagrammes d'image de l'architecture

Un diagramme peut être généré automatiquement à partir de la même configuration utilisée pour valider le code:

exemple de diagramme

Voir Tslint-Folders-Diagrams pour plus de détails.

Résumé des règles personnalisées

Voici un résumé des règles personnalisées actuelles.

ID de règle	Description
TSF-Folders-Hisabled-Test	Détecter un test unitaire désactivé, une suite de test ou un test d'intégration.
TSF-Folders-File-Names	Valide le boîtier des noms de fichiers. Semblable à la règle de règle standard `file-name-casing` sauf qu'il prend en charge plusieurs boîtiers autorisés et interdit les noms de fichiers avec des caractères non valides (tels que des espaces ou des virgules).
TSF-Folders-Import-From-Disallowed-Rolders	Détecter une importation à partir d'un dossier non standard comme Node_modules
TSF-Folders-Imports-Between-Packages	Détectez une importation à partir d'un package «de niveau supérieur»: par exemple, l'importation d'un package «shell» d'application lors d'un package «zone». Il s'agit de la règle personnalisée principale. Peut également détecter quand un package a des importations en utilisant ce nom de packages (au lieu d'un chemin relatif).
TSF-Folders-Test-with-Breakpoint	Détecter quand un test d'intégration a un point de rupture comme `browser.debug()`

sites

site	URL
Code source (github)	https://github.com/mrsanryan/tslint-folders
page github	https://mrsanryan.github.io/tslint-folders/
NPM	https://www.npmjs.com/package/tslint-folders

Approche adoptée

Toutes les règles utilisent le même préfixe tsf-folders- .

Pour indiquer clairement aux développeurs qu'une règle personnalisée est impliquée, tous les messages des règles incluent également l'ID de règle.

Certaines de ces règles pourraient être remplacées par la configuration TSLINT standard. Cependant, avoir des règles personnalisées donne des messages plus clairs pour aider le développeur à savoir quoi corriger (ou quelle règle désactiver pour ce morceau de code).

Certaines règles ne concernent pas strictement les «dossiers», mais sont inclus ici car ils semblent également utiles.

Pour plus de détails et d'exemples, veuillez consulter les tests unitaires

construire et tester ce code source

Pour travailler sur le code source pour Tslint-Folders, il y a quelques scripts:

commande	description
construction de fils	Construit les règles du dossier «dist», d'où ils peuvent être exécutés.
Lint de fil	Lint le code source des règles.
Start du fil	Construit, teste et peluche le code.
test de fil	Teste les règles contre les fichiers SPEC (* .lint)
Test-one du fil	Testez une seule règle par rapport aux fichiers SPEC (* .lint)

tests unitaires

Les tests unitaires pour la règle tsf-folders-imports-between-packages sont là.

Les tests unitaires utilisent les données de test pour vérifier les limites du package d'un site Web assez typique.

La configuration correspondante peut être vue dans tslint.tslint-folders.json

Données de test - Packages

Les données de test sont basées sur un site Web qui utilise plusieurs packages:

Nom de package	Description
coquille	Le shell d'application - il s'agit du package de niveau supérieur, et il peut importer à partir de tout autre package.
dans la région	Une zone «Todo App» du site Web, hébergé dans le shell. Il ne doit pas importer à partir du shell ou des autres packages «zone».
contact avec le toda	Une zone «Informations de contact» du site Web, hébergé dans le shell. Il ne doit pas importer à partir du shell ou des autres packages «zone».
emballage de grille	Une grille d'interface utilisateur utilisée par les packages de zone. Il ne devrait pas importer d'autres packages reconnus.
utils	Un package «utils» utilisé par les forfaits shell et zone. Il ne devrait pas importer d'autres packages reconnus.

Exemple de validation : `` Shell '' devrait être en mesure d'importer à partir de la «région de todo», mais pas l'inverse (Shell est à un niveau d'abstraction plus élevé, et souhaite également éviter les dépendances à 2 voies).

Données de test - Packages avec des sous-dossiers

TSLINT-RETOLDERS peut également valider les importations entre les sous-repliants d'un package.

Le package de données de test «todo-région» est configuré avec des sous-repliants assez typiques tels que «composants» et «modèles». Tslint.tslint-Folders.json a été configuré pour vérifier les importations entre ces dossiers.

Nom du sous-dossier	Description
composants	Dossier de niveau supérieur des composants d'interface utilisateur. Peut importer de l'un des autres dossiers reconnus.
vue de vue	Dossier de modèles de vue, utilisé par les composants de l'interface utilisateur. Ne peut être importée qu'à partir de modèles ou de utils.
modèles	Dossier de modèles, utilisé par les modèles de vue. Ne peut être importée qu'à partir des utils.
utils	Un dossier «utils». Il ne devrait pas importer d'autres dossiers reconnus.

Exemple de validation : les «composants» devraient être en mesure d'importer à partir de «modèles», mais pas l'inverse (les composants sont à un niveau d'abstraction plus élevé, et veulent également éviter les dépendances à deux voies).

Développement de code dans ce référentiel

Voir la lecture contributive.

origine

Ce projet est basé sur l'excellent projet Seeder TypeScript-Library-Starter.

Le projet a été lancé pour éviter d'avoir à résoudre à plusieurs reprises des problèmes de codage similaires dans de grandes bases de code de type dactylographiques.