ForHosting KIT · Outils pour développeurs

Valider noms de feature flags

Saisissez le nom d'un flag et voyez aussitôt s'il respecte la convention : enable-checkout-express est valide, avec le préfixe enable et trois segments en minuscules. Majuscules, séparateurs mélangés ou mot isolé échouent avec la liste des motifs. Gratuit dans votre navigateur.

Gratuit
Fonctionne dans votre navigateur
Sans inscription
Vos données restent sur votre appareil

Lancer gratuitement Voir l’API

Utilisez-le depuis WebAPIE-mailTelegramApp bientôt

Exemple résolu

Si vous saisissez

Nom: enable-checkout-express

Vous obtenez

Style: kebab
Préfixe: enable
Segments: enable, checkout, express
Nombre de segments: 3

Les feature flags (aussi appelés toggles, gates ou kill switches) ne restent gérables que si chaque nom suit une convention partagée. Mélanger casse, restes de camelCase, acronymes aléatoires et flags sans préfixe de verbe ou de domaine complique la recherche, casse les tableaux de bord et provoque des collisions entre équipes. Les écarts de convention renvoient un succès structuré avec valid à false et une liste ordonnée d'issues pour que l'intégration continue fasse échouer le build avec un rapport clair.

Ce qu'exige la convention de nommage

Un nom de feature flag sous cette convention est un identifiant machine court, pas de la prose libre. Mélanger traits d'union et underscores dans le même nom est un échec dur, tout comme une majuscule, un espace, une barre ou une autre ponctuation. Troisièmement, le nom doit se découper en au moins deux segments non vides pour qu'un mot isolé comme checkout ne parte jamais en production comme flag ; les équipes ont besoin d'un préfixe plus un corps descriptif.

Quatrièmement, le premier segment doit être un préfixe descriptif connu des catalogues courants : enable, disable, show, hide, allow, deny, use, is, has, can, feature, ff, exp, experiment, rollout, beta, alpha, new, legacy, dark, light, ops, ui, api, web, mobile, backend, frontend, gate, toggle, flag, release, kill, killswitch, perm ou temp. Cinquièmement, la longueur est plafonnée à soixante-quatre caractères pour rester compatible avec les stores de configuration, les variables d'environnement et les paramètres de requête URL.

Les séparateurs en tête, en fin ou doublés sont rejetés afin que le code généré et les filtres regex restent simples.

Contrat d'entrée, forme de réponse et erreurs

La valeur d'exemple enable-checkout-express est un flag kebab-case valide avec le préfixe enable. Lorsque le nom respecte toutes les règles, valid est true, issues est un tableau vide et style est kebab ou snake. Les nombres sont convertis en chaînes ; objets et tableaux sont rejetés.

Comme l'implémentation est parse pure de niveau A, les résultats sont stables d'un runtime à l'autre, sans réseau ni horodatage.

Où la validation des noms de flags apporte de la valeur

Les équipes plateforme et expérience développeur branchent cette vérification dans les générateurs de scaffolding pour qu'aucun nouveau flag n'arrive sans préfixe ni style de séparateur. Les jobs d'intégration continue scannent les pull requests qui touchent les catalogues de flags ou les fichiers d'environnement d'exemple et font échouer le build lorsqu'un nom tromperait les opérateurs six mois plus tard.

Les outils d'analytique produit et d'expérimentation appliquent les mêmes règles à l'enregistrement des clés de rollout pour que les tableaux de bord regroupent par préfixe de façon cohérente sur mobile, web et backend. Alignez la table des préfixes sur le style de votre organisation en mappant les verbes internes sur l'ensemble supporté, ou encapsulez ce point d'accès et rejetez tout préfixe que votre politique interdit même si la convention de base passe.

Cas d’usage

Scripts de migration et de nettoyage

Contrôlez en lot les flags hérités en camelCase ou UPPER_SNAKE et émettez une liste d'issues lisible par machine pour chaque candidat au renommage.

Questions fréquentes

Que se passe-t-il si le nom est vide ?

Les noms vides ou uniquement blancs ne peuvent pas être évalués face à la convention.

Quels préfixes descriptifs sont autorisés ?

Préfixes de catalogue courants tels que enable, disable, show, hide, feature, ff, exp, experiment, rollout, beta, api, ui, gate, toggle, release, kill et marqueurs d'aire ou d'intention similaires listés par le vérificateur.

Peut-on mélanger tirets et tirets bas dans un même nom ?

Non. Chaque nom utilise un seul style de séparateur d'un bout à l'autre : des tirets ou des tirets bas, jamais les deux. Les mélanger est un échec direct, comme une majuscule, une espace, une barre oblique ou toute ponctuation.

Pourquoi un mot seul comme checkout est-il refusé ?

Parce que la convention exige au moins deux segments non vides : un préfixe connu, comme enable ou rollout, puis un corps descriptif. Un mot isolé ne dit ni quel type d'interrupteur c'est, ni à quelle partie du produit il appartient.

Quelle longueur maximale pour le nom d'un flag ?

64 caractères. Cette limite garde les noms pratiques dans les fichiers de configuration, les variables d'environnement et les adresses web. Les séparateurs en début, en fin ou doublés sont aussi refusés.

Outils associés

Pour les développeurs — accès API

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

Endpoint

POSThttps://api.kit.forhosting.com/dev/feature-flag-name-validate

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

Appeler depuis votre stack

curl -X POST https://api.kit.forhosting.com/dev/feature-flag-name-validate \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"enable-checkout-express"}'

const res = await fetch("https://api.kit.forhosting.com/dev/feature-flag-name-validate", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "name": "enable-checkout-express"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/feature-flag-name-validate",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "name": "enable-checkout-express"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/feature-flag-name-validate", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"name":"enable-checkout-express"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"name":"enable-checkout-express"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/feature-flag-name-validate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Exemple de requête

{
  "name": "enable-checkout-express"
}

Exemple de réponse

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.feature_flag_name_validate",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

Tarifs

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

Erreurs

HTTP	Code	Signification
`401`	`unauthorized`	Clé API absente ou invalide : vérifiez l’en-tête Authorization.
`402`	`insufficient_balance`	Solde insuffisant : rechargez votre compte pour lancer cette tâche.
`404`	`unknown_type`	Type de tâche inconnu : vérifiez le champ type de votre requête.
`429`	`rate_limited`	Trop de requêtes : ralentissez la cadence, puis réessayez.

Notes techniques

Cette capacité valide un nom candidat selon un schéma pratique de l'industrie : non vide, entièrement en minuscules, en kebab-case à traits d'union ou en snake_case (jamais les deux séparateurs dans la même chaîne), au moins deux segments, préfixe descriptif tel que enable, feature, ff, rollout ou beta, soixante-quatre caractères au plus, sans séparateurs en bordure ni consécutifs. Une entrée vide échoue avec invalid_input et n'est pas facturée.

Ce qu'exige la convention de nommage

D'abord, il ne doit pas être vide ni constitué uniquement d'espaces : un nom vide est rejeté immédiatement en invalid_input car il n'y a rien d'utile à évaluer. Ensuite, chaque caractère doit être une lettre ASCII minuscule, un chiffre et exactement un style de séparateur : traits d'union pour le kebab-case ou underscores pour le snake_case. Ensemble, ces règles s'alignent sur les clés de style LaunchDarkly, les toggles Unleash et la plupart des fichiers JSON ou YAML internes sans inventer un dialecte propre à un éditeur.

Contrat d'entrée, forme de réponse et erreurs

En succès la réponse inclut toujours valid (booléen), le name après trim, style (kebab, snake ou null si le motif n'a pas pu être classé), prefix (premier segment ou null), segments comme tableau ordonné de chaînes, segment_count, has_descriptive_prefix, issues comme liste stable et ordonnée de codes lisibles par machine, et une courte phrase convention adaptée à l'interface. Lorsque le nom est présent mais viole la convention, valid est false et issues énumère des codes tels que not_lowercase, mixed_separators, missing_descriptive_prefix, too_few_segments, invalid_characters, consecutive_separators, leading_or_trailing_separator, too_long, missing_separator_segments ou invalid_pattern—sans lever d'exception—afin que linters et bots de pull request affichent tous les problèmes d'un coup. Seuls les noms vides, absents ou non chaîne lèvent invalid_input ; ces échecs ne consomment pas le solde prépayé.

Où la validation des noms de flags apporte de la valeur

Les bots de revue de code appellent l'API avec une chaîne candidate et collent la liste des issues dans le fil de revue au lieu de débattre du style selon le goût. Comme chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle, vous pouvez valider des milliers de noms dans un script de migration sans dépense surprise ; les envois vides restent gratuits en tant qu'erreurs client.

Cas d'intégration

Lint CI pour catalogues de flags

Analysez les fichiers YAML ou JSON de flags dans les pull requests et faites échouer le build si un nom est vide, mélange la casse ou manque de préfixe descriptif.

Scaffolding et générateurs CLI

Validez le nom saisi par un développeur avant d'écrire enable-foo-bar dans la configuration, les stubs SDK ou les tableaux de feature toggles.

Questions techniques

Qu'est-ce qu'un nom de feature flag valide ?

Une chaîne non vide en minuscules en kebab-case ou snake_case, au moins deux segments, premier segment un préfixe descriptif (par exemple enable, feature ou ff), 64 caractères au maximum, sans mélanger les séparateurs.

Les noms camelCase ou PascalCase sont-ils acceptés ?

Non. Les majuscules produisent not_lowercase dans la liste d'issues et valid est false. Convertissez d'abord en kebab-case ou snake_case.

Combien coûte le validateur de noms de feature flags ?

L'outil navigateur est gratuit. Les requêtes API utilisent le solde prépayé KIT à $0.002 par appel réussi ; une entrée vide invalide n'est pas facturée.

Consulter la documentation complète du KIT →

Lancer gratuitement

Exemple résolu

Ce qu'exige la convention de nommage

Contrat d'entrée, forme de réponse et erreurs

Où la validation des noms de flags apporte de la valeur

Cas d’usage

Scripts de migration et de nettoyage

Questions fréquentes

Outils associés

Pour les développeurs — accès API

Endpoint

Appeler depuis votre stack

Exemple de requête

Exemple de réponse

Tarifs

Erreurs

Notes techniques

Ce qu'exige la convention de nommage

Contrat d'entrée, forme de réponse et erreurs

Où la validation des noms de flags apporte de la valeur

Cas d'intégration

Lint CI pour catalogues de flags

Scaffolding et générateurs CLI

Questions techniques

merci