Résoudre la priorité des valeurs de configuration

Cette capacité compare les valeurs fournies par le réglage par défaut d’une application, un fichier de configuration, une variable d’environnement et une option de ligne de commande, puis applique l’ordre de priorité que vous définissez. Elle renvoie la valeur effective et sa source, afin que la décision soit facile à examiner, tester et documenter. Une source omise reste distincte d’une chaîne vide fournie volontairement, ce qui représente fidèlement les remplacements habituels.

Décrivez les valeurs sans perdre la notion d’absence

Placez les valeurs des sources dans l’objet values en utilisant les noms canoniques default, config_file, environment_variable et cli_flag. Une propriété absente signifie que cette source n’a pas fourni le réglage. Cette distinction est essentielle, car une chaîne vide peut constituer un remplacement intentionnel : une option CLI peut, par exemple, supprimer volontairement un préfixe présent dans un fichier. Le résolveur considère donc toute chaîne vide présente comme une véritable valeur et ne l’ignore jamais silencieusement. Chaque valeur fournie doit être une chaîne, comme les données brutes généralement issues des variables d’environnement et des analyseurs de ligne de commande ; cela évite les conversions inattendues entre zéro, faux et texte. Vous pouvez aussi indiquer le nom du réglage. Il ne modifie pas la sélection, mais figure dans le résultat afin que les journaux et scénarios de test restent lisibles lorsque plusieurs réglages sont évalués. Les noms de source inconnus sont refusés pour révéler les fautes de frappe. Si aucune des quatre propriétés n’est présente, la résolution échoue, notamment en l’absence de valeur par défaut.

Définissez et appliquez explicitement l’ordre de priorité

Le tableau precedence énumère les quatre sources de la priorité la plus élevée à la plus faible. L’ordre courant place l’option CLI, puis la variable d’environnement, le fichier de configuration et enfin la valeur par défaut. Le résolveur ne présume toutefois pas cette convention, car les applications et systèmes de déploiement diffèrent. Il parcourt les noms ordonnés et choisit la première source dont la propriété existe dans l’objet values. La source renvoyée explique pourquoi cette valeur a gagné, tandis que le tableau de priorité conserve la politique appliquée. Exiger chaque source prise en charge exactement une fois rend cette politique complète et vérifiable. Un nom dupliqué ou inconnu, une source manquante ou une entrée supplémentaire provoque une erreur de saisie plutôt qu’un résultat partiel ambigu. Cette rigueur est utile lorsque les règles viennent d’une documentation, d’une migration de framework ou d’une matrice de tests : l’ordre soumis constitue toute la règle. La sélection est déterministe et n’effectue aucune conversion de type, interpolation, lecture de fichier, consultation de l’environnement ou analyse de commande. La même entrée produit donc toujours la même sortie dans un navigateur, une tâche CI ou un appel API.

Exploitez le résultat dans les tests, diagnostics et documents

La réponse contient effective_value, source et l’ordre de priorité évalué. Si vous avez fourni un nom de réglage, elle l’inclut également. Cette structure compacte convient aux scénarios de test unitaire : rassemblez les valeurs brutes observées par votre chargeur, soumettez la politique voulue, puis vérifiez que la valeur gagnante et son origine correspondent aux attentes. Elle facilite aussi le diagnostic opérationnel. Un outil d’assistance peut montrer qu’un délai d’attente provient d’une variable d’environnement plutôt que d’un fichier versionné, sans reproduire tout le démarrage de l’application. Les équipes documentaires peuvent transformer des exemples de réglages superposés en démonstrations exécutables. Le résolveur ne consulte volontairement ni l’environnement du processus hôte, ni les fichiers, ni la syntaxe CLI. Il vous appartient de collecter ces entrées et de décider si des secrets doivent être envoyés ; préférez des valeurs fictives lorsque seul l’ordre est testé. Chaque requête résout un réglage et coûte $0.002 via l’API, tandis que le navigateur de niveau A emploie la même logique pure. Sans réseau, hasard, horloge ou état mutable, des requêtes identiques restent stables et faciles à comparer ou mettre en cache.