EnglishBac à sable

Variables d'environnement

Les valeurs qui atteignent le navigateur se déclarent, elles ne s'épellent pas. Une application liste les publiques dans fluixi.config.ts ; tout le reste reste sur le serveur, quel que soit son nom.

// fluixi.config.ts
import { defineConfig } from '@fluixi/start/config';

export default defineConfig({
  env: {
    public: ['AUTH_ISSUER', 'AUTH_CLIENT_ID', 'AUTH_TOKENS', 'API_URL', 'APP_URL'],
  },
});

La convention de Vite met la décision dans le nom : un préfixe VITE_ publie la valeur. Déplacer une valeur entre serveur et navigateur renomme alors chaque référence, et un secret nommé VITE_API_SECRET est publié, que quelque chose le lise ou non. Avec une liste, un secret ne peut atteindre le bundle qu'en y étant écrit.

Les lire

import { publicEnv, serverEnv } from '@fluixi/start/env';

const { API_URL } = publicEnv();                                    // anywhere
const secret = serverEnv('SESSION_SECRET', { required: true });     // server only

publicEnv() marche des deux côtés et renvoie le même ensemble figé de chaque côté. Dans le navigateur, le build l'a défini comme un littéral. Côté serveur, il lit process.env, réduit aux mêmes noms déclarés, pour qu'un loader ne puisse pas utiliser une valeur que le navigateur n'aura pas. Il marche aussi quand le serveur importe @fluixi/start depuis node_modules au lieu de l'embarquer, ce qui est le cas par défaut d'une installation publiée : là, import.meta.env vaut undefined, et un code qui le lit ne casse qu'en production.

serverEnv(name) lit une variable réservée au serveur. Dans un navigateur, il lève une erreur au lieu de renvoyer undefined, car un secret lu comme undefined devient une requête envoyée sans credentials, et l'échec pointe alors vers la requête au lieu de la lecture. { required: true } lève aussi une erreur quand la variable n'est pas définie, en la nommant.

D'où viennent les valeurs

fluixi dev et fluixi start chargent .env, .env.local, .env.<mode> et .env.<mode>.local dans process.env côté serveur, toutes les variables, préfixées ou non. Une variable déjà définie dans l'environnement réel l'emporte sur les fichiers : c'est ainsi que les secrets propres à un déploiement remplacent le .env d'un développeur.

Le préfixe VITE_

Il continue de marcher. Un nom déclaré est trouvé sous son écriture nue ou précédé de VITE_, l'écriture nue d'abord, donc .env peut migrer une variable à la fois : AUTH_ISSUER dans env.public lit VITE_AUTH_ISSUER jusqu'à ce qu'elle soit renommée. Ce qui est déjà préfixé reste public, comme toujours.

Ce qui empêche un secret de partir

La liste est la protection. Trois contrôles rattrapent la ligne écrite trop vite :

Contrôle Quand Ce qui se passe
un nom de env.public ressemble à un secret (SECRET, PASSWORD, PRIVATE_KEY, CREDENTIALS) build refusé, en le nommant
une variable VITE_ d'un fichier .env ressemble à un secret fluixi build refusé ; fluixi dev avertit
serverEnv() appelé dans le navigateur exécution lève une erreur

Pour un nom qui ne fait que ressembler à un secret, FLUIXI_ALLOW_PUBLIC_SECRETS=true laisse passer le build.

Suite : SEO et en-tête de document.