Ce qu’Agnes comprend, et ce qu’il ne comprend pas encore

Pris en charge signifie que la vérification s’exécute et connaît les conventions du framework. En partie signifie qu’elle s’exécute avec les limites décrites plus bas. Pas encore signifie que la vérification est ignorée pour ce framework.

• TanStack Start

  Les routes et l’arbre de routes généré comptent comme points d’entrée, donc les fichiers de routes ne sont jamais signalés comme inutilisés. Les paquets propres au framework ne sont pas vérifiés pour savoir s’ils sont inutilisés.

• React Router and Remix

  Les routes du dossier app et les fichiers cités dans routes.ts comptent comme points d’entrée. routes.ts est lu comme du texte, jamais exécuté : pour les routes construites par du code, comme des boucles ou des fonctions utilitaires, les fichiers peuvent donc être signalés comme inutilisés.

• Solid, Qwik and Preact

  Analysé comme du TypeScript et du JSX classiques. Nous n’avons pas testé ces frameworks en particulier : les règles propres à React peuvent donc signaler des choses qui sont correctes ici, et les résultats sur le code mort dépendent d’un index.html ou d’un point d’entrée dans package.json.

• Vue

  En plus des vérifications du code et des templates, Agnes signale les props qu’un composant modifie, les refs utilisées sans .value et v-html (un constat de sécurité à examiner). Les blocs style sont lintés quel que soit leur lang. Les avertissements de dépréciation de Vue 2 sont écartés.

• Nuxt

  Les pages, layouts, middlewares, plugins et le code serveur comptent comme points d’entrée. C’est aussi le cas des dossiers components, composables, utils et stores, car Nuxt les importe automatiquement : le code inutilisé dans ces dossiers n’est donc pas signalé.

• Svelte

  Les avertissements du compilateur Svelte sur la réactivité et les styles inutilisés sont signalés, ainsi que des règles d’eslint-plugin-svelte comme les clés each manquantes et {@html} (un constat de sécurité à examiner). La règle qui signale chaque lien interne n’utilisant pas resolve() est écartée, car trop bruyante.

• Astro

  Les pages sont des points d’entrée, et les scripts, templates et styles des composants sont vérifiés. Les vérifications d’accessibilité pour Astro couvrent les templates.

• Angular

  Le TypeScript, les templates et les templates inline sont vérifiés avec les règles de lint recommandées d’Angular, et les feuilles de style des composants sont lintées comme les autres (::ng-deep, :host et :host-context sont compris). Les styles inline écrits dans le décorateur du composant ne sont pas lintés. Les templates sont trouvés via le templateUrl de chaque composant, les noms de fichiers n’ont donc pas d’importance.

• Stylus

  Les fichiers Stylus ne sont pas analysés. Le seul parseur disponible pour Stylus n’est plus maintenu et lit mal la syntaxe Stylus courante. SCSS, Sass et Less sont lintés, avec les règles CSS et SCSS standard.

• Score de maintenabilité des scripts de composants

  La complexité cognitive est mesurée dans les scripts des fichiers .vue, .svelte et .astro, mais le score de maintenabilité par fichier ne lit que les fichiers JavaScript et TypeScript.

• Un lockfile est nécessaire

  Les vérifications des dépendances, des avis et des licences lisent package-lock.json, yarn.lock, pnpm-lock.yaml ou bun.lock, et la vérification des avis lit aussi composer.lock. Sans lockfile, cette partie du score est écartée.

• npm, plus les avis Composer

  Les paquets Composer sont vérifiés pour les avis connus, mais pas pour leur obsolescence ni pour leurs licences. Les dépendances d’autres écosystèmes, ou de Deno, ne sont pas vérifiées.

• Votre propre configuration de lint n’est pas lue

  Agnes exécute ses outils avec ses propres règles dans un bac à sable et n’exécute jamais vos fichiers de configuration : les règles ESLint, Biome ou Stylelint propres à votre projet ne changent donc pas le rapport.

• Des dépôts surtout frontend

  Au moins 60 % des lignes de code source doivent être du code frontend. Un monorepo avec beaucoup de code backend peut passer sous ce seuil et n’est alors pas analysé. Les templates (Blade, Twig, Nunjucks, Handlebars, Liquid, MDX) ne comptent d’aucun côté : les vues Blade d’une application Laravel ne la font donc pas passer sous ce seuil.