Environnement et configuration

Effectuez une modification de configuration et vérifiez-la

Commencez avec une application Web en cours d’exécution. Dans l'éditeur, ouvrez apps/web/.env.local ; s'il n'existe pas, copiez-y .env.example à l'aide du didacticiel Web. Pour une première vérification inoffensive, recherchez EMAIL_PROVIDER=local et laissez-le local. Ce paramètre envoie l'e-mail du produit vers l'aperçu local au lieu d'une véritable boîte de réception. Ne collez pas les lignes KEY=value dans le terminal.

Pour chaque service que vous activez, suivez le guide de configuration de ce fournisseur, remplacez uniquement les valeurs nommées, enregistrez le fichier, arrêtez le serveur Web avec Ctrl + C et redémarrez avec la commande ci-dessous. Si la validation nomme une clé manquante, rouvrez ce fichier et comparez cette clé avec le guide du fournisseur. Gardez root .env synchronisé uniquement pour les valeurs utilisées par les migrations de bases de données ; le copier seul ne configure pas Next.js.

• Rechercher une clé de configuration
• Apprenez à exécuter une commande et à modifier un fichier

corepack pnpm --filter @supastack/web dev

Commencer par l’exemple d’environnement

Le .env.example racine est l’inventaire de configuration. La validation partagée se trouve dans packages/config. Examinez ensemble l’environnement choisi et les modes des fournisseurs ; une interface locale ne constitue pas une stratégie d’identifiants de production.

Le mode de référence sans identifiants exige une configuration d’application locale/de test et des fournisseurs fake/local. Le choix d’un fournisseur de production modifie les exigences du runtime.

Garder les secrets derrière l’API

Les secrets d’authentification, identifiants de base, clés de fournisseurs, secrets Stripe et identifiants Trigger sont réservés au serveur. Ne leur ajoutez jamais le préfixe NEXT_PUBLIC_ ou EXPO_PUBLIC_. Ne les affichez pas pendant la configuration et ne les incluez pas dans les réponses d’erreur.

Le navigateur reçoit la configuration publique et les alias de modèles autorisés. La propriété de l’espace de travail, les décisions de droits, les budgets et le choix des fournisseurs restent imposés par le serveur.

Vérifier un changement avant de l’utiliser

Validez la configuration avec le package config existant et exécutez les tests déterministes pertinents. Lorsque vous souhaitez valider de vraies intégrations, utilisez le parcours d’essai fournisseur auquel vous avez choisi de participer séparément.

corepack pnpm test
corepack pnpm check
corepack pnpm build

Configuration et paramètres

packages/config est le seul endroit qui parse process.env : un schéma zod produit un ServerConfig et un PublicConfig typés, et la sélection de fournisseurs s'exprime en kinds — providers.ai, providers.billing, providers.email, providers.jobs, providers.storage se résolvent chacun en un adaptateur nommé plus ses champs requis.

Activer un fournisseur rend ses identifiants requis : activer une connexion sociale, le kind de stockage s3 ou le kind e-mail resend fait échouer le démarrage en nommant la variable manquante, plutôt qu'une surprise au runtime plus tard.

STORAGE_PROVIDER=s3
STORAGE_BUCKET=kit
STORAGE_ENDPOINT=https://s3.example
STORAGE_PUBLIC_BASE_URL=https://cdn.example
# → config rejects the env if a required field is missing

Processus d’implémentation

Lisez la config via parseServerConfig à la frontière serveur et passez la valeur typée vers l'intérieur — ne touchez pas process.env dans le code des fonctionnalités. La config publique est un objet séparé, volontairement petit, sûr à sérialiser vers le client.

L'env spécifique au produit appartient au schéma propre du produit consommateur. Résistez à faire grossir le schéma du kit pour les besoins d'un seul produit.

Vérification et dépannage

Exécutez les tests du package config après avoir changé le schéma, et vérifiez qu'une variable requise manquante se nomme dans l'erreur. Un env qui parse en local mais pas en production signifie généralement un champ requis non documenté.