Valider une configuration

sovrium validate décode un fichier de configuration face à AppSchema — le schéma que le serveur décode au démarrage — et signale chaque problème trouvé. La commande ne touche aucune base de données, ne lie aucun port et n'exige aucun environnement : c'est donc l'endroit le moins coûteux pour attraper une configuration cassée.

sovrium validate app.yaml
sovrium validate config.json
sovrium validate app.ts

Elle accepte .json, .yaml, .yml et .ts, et résout chaque inclusion $ref avant toute vérification — une configuration répartie sur vingt fichiers est donc validée comme l'objet unique qu'elle devient.

À quoi ressemble un succès

Valid configuration: my-app

Code de sortie 0. Comme il s'agit du même décodage que celui effectué au démarrage, une configuration qui valide démarrera.

À quoi ressemble un échec

Les problèmes s'affichent en arbre indenté sous un seul en-tête, avec le code de sortie 1.

Lisez-le par le bas. L'arbre descend à travers le schéma avant d'atteindre votre configuration : le haut est de la mécanique — des dizaines de lignes From side refinement failure — et les deux dernières lignes portent le constat.

Validation failed:
  { { { { App | filter } | filter } | filter } | filter }
  └─ From side refinement failure
     ... (de nombreuses lignes similaires)
                 └─ App
                    └─ ["tabels"]
                       └─ is unexpected, expected: "name" | "version" | "description" | ...

Celui-ci dit : vous avez écrit tabels, et ce n'est pas une propriété. Passer par tail est une habitude raisonnable :

sovrium validate app.yaml 2>&1 | tail -5

Les trois classes d'erreur

Classe	Exemple	Détectée par
Structurelle	name manquant ; un nombre donné à une chaîne	Le décodage AppSchema
Propriété non reconnue	tabels: au lieu de tables:	Le rejet des propriétés en excès
Type de champ inconnu	type: web-site sur un champ de table	Le balayage post-décodage

La deuxième mérite qu'on s'y arrête : sovrium validate rejette les propriétés que le schéma ne connaît pas, au lieu de les ignorer. Sans cela, une clé mal orthographiée serait silencieusement écartée, et la fonctionnalité que vous croyiez avoir configurée n'apparaîtrait tout simplement jamais.

La troisième s'exécute après le décodage, et s'affiche en clair plutôt qu'en arbre :

Validation failed:
  Unknown field type "web-site" in field "website"

Avec une configuration multi-fichiers, le constat est attribué à la partie dont il provient — companies.yaml: Unknown field type ....

Codes de sortie

Code de sortie	Signification
0	La configuration est valide
1	Configuration invalide (erreur de décodage, type de champ inconnu, fichier absent)

Tout échec vaut 1 : contrôler un pipeline tient donc en une ligne.

sovrium validate app.yaml || exit 1

Exécutez-la avant l'étape de déploiement. C'est le dernier point où une mauvaise configuration coûte des secondes plutôt qu'un retour arrière.

Validation programmatique

Pour valider dans un script plutôt que dans un shell, validateConfig() retourne le résultat sous forme de données au lieu de quitter :

import { validateConfig } from 'sovrium'

const result = validateConfig(JSON.parse(await Bun.file('app.json').text()))
if (!result.valid) console.error(result.errors.join('\n'))

Elle est délibérément plus permissive que le CLI : elle tolère les propriétés non reconnues et saute le balayage des types de champ inconnus. Utilisez-la comme garde-fou en mémoire, et gardez sovrium validate comme barrière avant déploiement. Détails complets sur Validation et génération de schéma.

Pages associées

• Commandes de projet — sovrium validate aux côtés d'init, build, schema.
• Configuration de l'éditeur — attraper les erreurs structurelles à la frappe.
• Configurations multi-fichiers — comment les fichiers $ref sont attribués dans les erreurs.
• Dépannage — les autres erreurs qu'un démarrage peut afficher.