wotan

Le projet Fimbullinter

TypeScript et JavaScript Linter

Forfaits disponibles

Wotan

Le runtime principal de Linter avec un ensemble bien choisi de règles intégrées. Personnalisable avec vos propres règles, processeurs, formateurs, configurations partageables et modules de plugin.

Veuillez vous référer aux documents pour une explication détaillée des règles, configuration et utilisation disponibles.

Vé

Processeur officiel pour les composants de fichier unique VUE (SFC). Extrait le contenu du script de vos fichiers *.vue pour la liaison.

Heimdall

Couche de compatibilité pour permettre l'utilisation de règles et de formateurs TSLINT à l'intérieur du temps d'exécution de Wotan.

Valtýr

Faites en sorte que Wotan se comporte presque comme Tslint. Réutilisez votre tslint.json existant sans aucun changement.

Bifröst

Permet aux auteurs de règles et de formateurs TSLINT de fournir leur package pour l'utilisation à l'intérieur de Wotan. Les règles et les formateurs qui utilisent Bifröst n'ont pas besoin que Heimdall fonctionne correctement.

Ymir

Fournit des types de base pour les règles personnalisées et les auteurs de plugin.

Mímir

Contient toutes les règles de base, formateurs et préréglages de configuration.

Mithotyn

Plugin LanguageService pour TypeScript. Fournit la libellé en temps réel pendant que vous tapez.

Documentation supplémentaire

• Comprendre l'API de TypeScript
• Règles d'écriture
• Règles de test
• En utilisant des règles locales
• Écrire des configurations partageables
• Utilisation de l'API

Recettes

• Fichiers Vue libin avec des règles Tslint
• Remplacement de tslint --type-check
• Détecter les variables inutilisées

De quoi s'agit-il?

Qu'est-ce qui se passe avec ces noms?

Mythologie nordique:

Fimbullinter vient de Fimbulwinter, l'hiver durable de 3 ans qui précède les événements de Ragnarök. «Fimbul» signifie «Grand», «Linter» est un outil qui détecte et met en garde contre certains modèles de codage.

Wotan est l'un des nombreux noms d'Odin, le tout-père. Vous pouvez également le connaître par le nom de Woden, Wodan, Wensley, etc. Woden est un Dieu sacrificiel, sanguinaire et cruel. Il cherche constamment la sagesse. De son trône, il peut voir tout dans les neuf mondes.

Vé est le plus jeune des trois dérange Woden, Vili et Vé qui ont ensemble le géant Ymir et ont créé les neuf mondes de son corps.

Au premier couple humain, demandez et Embla, Odin a donné l'âme et la vie; Vili a donné l'esprit (intelligence) et le sens du toucher; et Vé a donné un visage (apparence, expression faciale), une parole, une audition et une vue.

Heimdall (également connu sous le nom de Heimdallr), situé où le pont arc-en-ciel brûlant Bifröst rencontre le paradis, garantit le début de Ragnarök.

Bifröst est le pont arc-en-ciel brûlant qui relie le monde de l'homme au royaume des dieux.

Valtýr , de "Valr" (les morts, tués au combat) et "Týr" (Dieu), signifie Dieu des tués et est souvent utilisé pour désigner Odin.

Ymir est le géant dont le corps entier a été créé. Il est l'ancêtre de tout Jötnar.

Mímir ("The Remember, The Sage One") réputé pour ses connaissances et sa sagesse. Le dieu Odin porte autour de la tête de Mímir et il récite des connaissances secrètes et des conseils à lui.

Mithotyn (en fait "Mitoðinn", qui signifie "distributeur du destin") introduit des règles là où il n'y en avait pas. Remplace la place d'Odin lors de ses voyages sur des terres étrangères.

Pourquoi encore un autre linter?

Celui-ci essaie d'éviter les décisions de conception d'autres liners qui se sont avérés problématiques:

• Évitez les conflits de noms en préfixant les noms de règles en fonction du package dont ils proviennent.
  • Tslint met toutes les règles dans un espace de noms global et les recherche dans tous les répertoires de règles disponibles. L'ordre des répertoires est importante tandis que les règles de base L'écran prioritaire a priorité.
  • Eslint permet un répertoire de règles local comme indicateur CLI. Les règles de ce répertoire peuvent remplacer les règles de base.
• Les dépendances des fichiers de configuration sont résolues par rapport à ce fichier.
  • Tslint fait déjà cela.
  • Eslint ne prend pas en charge cela.
• Aucune distinction entre les configurations et plugins partageables. En fait, les deux ne sont que des configurations extensibles qui peuvent éventuellement fournir des répertoires de règles, des paramètres, des règles et des processeurs.
  • Tslint vous permet de choisir entre extends et rulesDirectory . Le répertoire des règles d'un package est un détail d'implémentation et ne doit pas faire partie de la configuration de l'utilisateur.
  • Eslint gère les configurations et les plugins assez différents. En fait, ils ont essayé de déprécier les configurations partageables en faveur des plugins.
• Chargement paresseux des règles pour réduire le temps de démarrage.
  • Tslint fait déjà cela.
  • Eslint s'attend à ce que les plugins fournissent les règles en tant qu'objets déjà chargés. Cela provoque beaucoup de frais généraux si vous n'utilisez que quelques règles d'un gros package.
• Cache de l'accès et de la configuration du système de fichiers. Comme le cache est un service DI, les utilisateurs d'API peuvent effacer le cache en cas de besoin.
• Prise en charge des processeurs depuis le début. Activation de la liaison des fichiers * .vue et bien d'autres.
• Alias ​​pour les règles avec configuration. Peut être utilisé pour traiter des règles telles que no-resticted-syntax d'Eslint comme des règles nommées distinctes pour chaque option de configuration.
• L'API entière est alimentée par un conteneur DI. Cela facilite l'injection d'un service différent. Vous pouvez même utiliser des plugins via la CLI pour injecter différents services.
• Fichier de configuration "global" (en plus .wotanrc.yaml ) pour les paramètres CLI et la configuration du plugin: .fimbullinter.yaml . Ce fichier peut également être utilisé par les plugins d'éditeur, il n'est donc pas nécessaire de dupliquer la configuration commune.
  • Eslint n'a pas un tel fichier et a refusé d'en ajouter un à l'avenir. Des outils comme standard ou xo n'auraient pas besoin d'exister si vous aviez simplement besoin de créer un tel fichier de configuration avec des paramètres par défaut CLI.
  • Tslint Startet pour le fourrer dans leur tslint.json ce qui conduit à des utilisateurs confus.
• Signalez inutilisé et redondant Activer et désactiver les commentaires (ou des parties de celui-ci) avec --report-useless-directives .
  • Eslint ne rapporte que des commentaires désactivés inutilisés. Il ne rapporte que des commentaires complètement inutilisés. Les commentaires redondants ne sont pas signalés et permettent des commentaires pour des règles inexistantes.
  • Tslint ne prend pas en charge cela.

Différences avec Tslint

• Pour étendre un plugin ou une configuration partageable, utilisez extends: plugin-name . Le nom sera résolu en fonction de l'algorithme de résolution du module de Node par rapport au fichier de configuration.
• Pour utiliser les règles maintenues à l'intérieur de votre projet, utilisez rulesDirectory: {"my-prefix": "./path/to/rules"} et configurez-les en tant que my-prefix/rule-one: "error" . Le répertoire des règles est un chemin par rapport au fichier de configuration.
• Remplacements: vous pouvez remplacer la cofiguration principale en spécifiant un ou plusieurs remplacements. Si le nom de fichier correspond au modèle global du remplacement, tous les paramètres fournis par cette remplacement sont appliqués. Les remplacements sont traités dans l'ordre, les dépassements de remplacements de remplacements ultérieurs provenant de remplacements précédents.
  • Les modèles correspondent par rapport au fichier de configuration dans lequel ils sont spécifiés.
  • Les modèles sans barre oblique ne sont égalés qu'avec le nom de base de chaque fichier.
  • Pour limiter une correspondance au répertoire actuel, préfixez le modèle avec ./ .
  • Les modèles niés peuvent être utilisés pour soustraire des correspondances des modèles précédents.
• linterOptions.exclude -> exclude
  • Les exclusions ne sont pas remplacées lors de l'extension d'une configuration.
  • La correspondance du modèle suit les mêmes règles que les remplacements (voir ci-dessus).
• Prise en charge JSON5 pour les fichiers config.
• Paramètres indépendants des règles que les règles et les processeurs peuvent reprendre.
• Processeurs, même supporte --project .
• Alias, voir ci-dessus
• Une approche saine et sûre de la fixation:
  • Ne corrige pas les fichiers avec des erreurs de syntaxe.
  • Exclut les remplacements qui se chevauchent pour éviter de détruire votre code.
  • Exécute un nombre configurable d'itérations par fichier pour appliquer des modifications conflictuelles dans la prochaine itération.
  • Arrête si les correctifs introduiraient les erreurs de syntaxe.
  • La fixation avec --project ne crée pas l'ensemble du programme à partir de zéro, ce qui le rend rapide.
• Essai
  • Les tests sont configurés dans des fichiers JSON qui peuvent configurer tout ce que vous pouvez spécifier par la CLI
  • Les fichiers de test ne contiennent pas de balisage d'erreur. Cela évite les erreurs de syntaxe et les rend plus faciles à maintenir. Les résultats des peluches et le contenu fixe sont stockés dans des fichiers de référence distincts.
  • Le même code peut être testé avec différents paramètres.
• Prend en charge les références de projet TypeScript.
• Charge les valeurs par défaut pour les options CLI de .fimbullinter.yaml .
• N'utilise pas les informations de type dans des fichiers JavaScript non cochés ( // @ts-nocheck ou "checkJs": false ).
• Les rapports inutilisés et redondants permettent et désactivent les commentaires avec --report-useless-directives .

Environnements pris en charge

Ce projet fonctionne sur toutes les versions activement prises en charge de Node.js.

Ce projet soutient officiellement la dernière version stable de TypeScript. En ce qui concerne la rédaction, il s'agit de 3,0 à 3.2. Cela devrait fonctionner avec les builds nocturnes de TypeScript ( typescript@next ), mais il n'y a aucune garantie.

Les règles personnalisées devraient au moins utiliser ES6 pour avoir une prise en charge des classes natives. Sinon, vous rencontrez des problèmes lorsque vous essayez d'étendre les classes exportées de l'un des packages.

Versioning sémantique (politique SEMVER)

️ La politique suivante ne s'applique que pour les versions 1.x et suivantes. Chaque version de la plage 0.x est considérée comme expérimentale. Il peut et cassera les changements d'API sans dépréciation.

En théorie, chaque changement en règle peut enfreindre les utilisateurs et peut être considéré comme un changement de rupture. Pour éviter de publier une nouvelle version majeure pour chaque correction de bogue, nous avons des directives légèrement différentes comme indiqué ci-dessous.

Préréases (construction nocturne)

• ne sont pas garantis pour être stables
• Tagué comme next sur NPM afin que vous puissiez installer @fimbul/wotan@next
• Contient les derniers modifications destinées à la prochaine version
  • x.0.0-dev* contient tous les modifications, y compris les ruptures pour la prochaine version principale
  • xy0-dev* contient toutes les modifications pour la prochaine version mineure
  • Il n'y a pas de pré-aliments pour les versions de patch

Rejets de correctifs

• Corre des collisions
• Corre des régressions
• Refactorisations de fonctionnalités internes qui ne modifient pas le comportement de la face des utilisateurs

Sorties mineures

• Ajoute de nouvelles règles, des options de règles, des formateurs, des processeurs, des API
• Les règles peuvent ajouter de nouveaux chèques qui peuvent conduire à de nouvelles découvertes
• De nouvelles règles et options sont activées dans wotan:latest
• Les règles peuvent modifier leurs messages de recherche
• Les formateurs destinés à la consommation humaine (par exemple stylish ) peuvent modifier leur production
• Les règles, les options de règles, les formateurs, les processeurs et les API peuvent être obsolètes
• De nouvelles options de configuration peuvent être ajoutées aux fichiers de configuration

Sorties majeures

• Contient les changements de rupture de l'API
• Supprime les règles, les options, les formateurs, etc.
• Les formateurs destinés à la consommation de machines (par exemple json ou tap ) peuvent modifier leur sortie
• wotan:recommended est mis à jour au contenu de wotan:latest

Sortie à la publication

Actuellement, il n'y a pas de calendrier de version fixe. Les constructions nocturnes sont publiées tous les soirs s'il y a des modifications sur Master. Les versions de correctifs sont publiées dès que les bogues sont identifiés et corrigées. Des versions mineures sont publiées chaque semaine ou deux s'il y a des modifications sur Master. Des versions majeures sont publiées une fois que suffisamment de changements de rupture se sont accumulés.

Licence

Apache-2.0 © Klaus Meinhardt