sv check

sv check détecte les erreurs et les warnings présents dans votre projet, comme par exemple :

• du CSS non utilisé
• des astuces d’accessibilité
• des erreurs de compilateur liées à JavaScript/TypeScript

Nécessite Node 16 ou plus récent.

Installation

Vous aurez besoin d’avoir le paquet svelte-check installé sur votre projet :

npm i -D svelte-check

Usage

npx sv check

Options

--workspace <path>

Path vers votre workspace. Tous les sous-dossiers à l’exception de node_modules et de ceux listés avec --ignore sont vérifiés.

--output <format>

Comment afficher les erreurs et les warnings. Voir output conçu pour les machines.

• human
• human-verbose
• machine
• machine-verbose

--watch

Conserve le processus actif et écoute les changements.

--preserveWatchOutput

Empêche l’écran d’être effacé en mode watch.

--tsconfig <path>

Fournir un path vers un fichier tsconfig ou jsconfig. Le path peut être relatif au path du workspace ou absolu. Utiliser cette option implique que seuls les fichiers correspondant aux motifs décrits par files / include/exclude de votre fichier de configuration seront diagnostiqués. Cela implique également que les erreurs des fichiers TypeScript et JavaScript sont remontées. Si non fourni, la vérification traversera le projet depuis sa racine à la recherche du fichier jsconfig/tsconfig suivant.

--no-tsconfig

Utilisez cette option si vous souhaitez uniquement vérifier les fichiers Svelte trouvés dans et en-dessous du dossier actuel, en ignorant les fichiers .js / .ts (leur typage ne sera pas analysé).

--ignore <paths>

Les fichiers/dossiers à ignorer, relativement à la racine du workspace. Les paths doivent être entre guillemets et séparés par des virgules. Exemple :

npx sv check --ignore "dist,build"

N’a d’effet que lorsqu’utilisé avec no-tsconfig. Lorsqu’utilisé avec --tsconfig, ceci n’aura d’effet que sur les fichiers observés, pas sur les fichiers diagnostiqués, qui sont déterminés par le tsconfig.json.

--fail-on-warnings

Si fourni, les warnings provoqueront l’arrêt de sv check avec un code d’erreur.

--compiler-warnings <warnings>

Une liste de valeurs code:behaviour entre guillemets et séparées par des virgules où code est un code de warning compilateur et behaviour est soit ignore soit error :

npx sv check --compiler-warnings "css_unused_selector:ignore,a11y_missing_attribute:error"

--diagnostic-sources <sources>

Une liste de types de sources entre guillemets et séparées par des virgules qui doivent être analysées. par défaut, elles sont toutes actives.

• js (inclut TypeScript)
• svelte
• css

Exemple :

npx sv check --diagnostic-sources "js,svelte"

--threshold <level>

Filtre les diagnostics :

• warning (défaut) — les erreurs et les warnings sont affichés
• error — n’affiche que les erreurs

Résolution de problèmes

Voir la documentation des outils pour plus d’informations sur la mise en place des préprocesseurs ou tout autre type d’assistance.

Outputs machine

Définir l’option --output à machine ou machine-verbose permet de formatter l’output d’une manière adaptée à la lecture par des machines, c-à-d au sein de pipelines CI, lors de vérifications de qualité de code, etc.

Chaque ligne correspond à un nouvel enregistrement. Les lignes sont constituées de colonnes séparées par un espace. La première colonne de chaque ligne contient un timestamp en millisecondes pouvant être utilisé pour du suivi. La deuxième colonne fournit le “type de ligne”, en fonction duquel le nombre et type de colonnes suivantes peuvent changer.

La première colonne est de type START et contient le dossier du workspace (entre guillemets). Exemple :

1590680325583 START "/home/user/language-tools/packages/language-server/test/plugins/typescript/testfiles"

Un nombre quelconque d’enregistrements ERROR ou WARNING peuvent suivre. Leur structure est identique et dépend de l’argument d’output.

Si l’argument est machine, le nom de fichier, la position initiale en numéro de ligne et colonne, ainsi que le message d’erreur seront affiché. Le nom de fichier est relatif au dossier de workspace. Le nom de fichier et le message sont tout les deux entre parenthèses. Exemple :

1590680326283 ERROR "codeactions.svelte" 1:16 "Cannot find module 'blubb' or its corresponding type declarations."
1590680326778 WARNING "imported-file.svelte" 0:37 "Component has unused export property 'prop'. If it is for external reference only, please consider using `export const prop`"

Si l’argument est machine-verbose, le nom de fichier, la position initiale en numéro de ligne et colonne, la position finale en numéro de ligne et colonne, le message d’erreur, le code de diagnostic, une description du code et la source du diagnostic (c-à-d svelte/typescript) lisibles par l’humain seront affichés. Le nom de fichier est relatif au dossier de workspace. Chaque diagnostic est représenté par une ligne ndjson préfixée par le timestamp du log. Exemple :

1590680326283 {"type":"ERROR","fn":"codeaction.svelte","start":{"line":1,"character":16},"end":{"line":1,"character":23},"message":"Cannot find module 'blubb' or its corresponding type declarations.","code":2307,"source":"js"}
1590680326778 {"type":"WARNING","filename":"imported-file.svelte","start":{"line":0,"character":37},"end":{"line":0,"character":51},"message":"Component has unused export property 'prop'. If it is for external reference only, please consider using `export
const prop`","code":"unused-export-let","source":"svelte"}

L’output se termine par un message COMPLETED qui résume le nombre total de fichiers, d’erreurs et de warnings rencontrés pendant le processus. Exemple :

1590680326807 COMPLETED 20 FILES 21 ERRORS 1 WARNINGS 3 FILES_WITH_PROBLEMS

Si l’application produit une erreur d’exécution, cette erreur sera affichée comme un enregistrement FAILURE. Exemple :

1590680328921 FAILURE "Connection closed"

Crédits

• Le projet Vue VTI qui a servi de fondation pour svelte-check

FAQ

Pourquoi n’y a t’il pas d’option pour analyser uniquement des fichiers spéficiques (comme les fichiers en staging) ?

svelte-check a besoin de “voir” tout le projet pour pouvoir effectuer correctement ses vérifications. Supposez que vous ayez renommé une prop d’un composant sans mettre à jour les différents endroit où cette prop est utilisé — tous les fichiers où cette prop est utilisée ont alors une erreur, mais vous ne la verriez pas si vous analysiez uniquement les fichiers modifiés.