Variables d'environnement

Toutes les variables lues par @lrvo/core. La source de vérité est le catalogue src/core/doctor/env.js, où le core déclare ce qu'il sait lire, comme un module le fait dans son manifest.envVars. Une variable lue par le code sans y figurer fait échouer npm run build, et l'inverse aussi.

Le fichier .env.example est autre chose : le modèle de démarrage copié par @lrvo/start dans un nouveau projet, réduit à ce qu'il faut remplir pour que le site tourne. Une variable peut donc exister ici sans figurer au modèle, et c'est le cas de tout ce qui a une valeur par défaut satisfaisante. Cette page les liste toutes.

Variables requises

Trois seulement. Leur absence fait sortir lrvo-doctor en erreur, parce qu'aucune configuration légitime ne s'en passe :

Le stockage, le courriel et les paiements restent optionnels : un projet sans téléversement, sans courriel transactionnel ou sans paiement est une configuration valide, et le diagnostic ne doit pas contredire la tuile de santé de l'admin, qui les affiche en avertissement et jamais en erreur.

Les variables LRVO_* sont serveur uniquement. Seules les NEXT_PUBLIC_* existent dans le bundle navigateur. Un composant client qui lit une variable LRVO_* reçoit undefined sans erreur, et le flag se comporte comme désactivé en silence. Voir Configuration de l'app.

Général

Sans URL publique configurée, la vérification CSRF refuse les requêtes mutantes.

Les trois variables de marque sont lues par getPublicBrand() et servent de repli à tous les modules qui servent une page publique : un site qui signe partout sous la même enseigne les déclare une fois ici, un site qui partage ou facture sous une autre enseigne surcharge le module concerné. LRVO_LOGO_URL est l'image du logo, à ne pas confondre avec LRVO_EMAIL_LOGO_URL, qui est la destination du lien posé autour du logo des courriels. Sur une page publique, getPublicBrand().name ne retombe pas sur le défaut LRVO : sans LRVO_NAME, la ligne de marque du pied de page ne s'affiche pas plutôt que de signer le site d'un nom inventé.

Régional

Proxy

À activer uniquement derrière un reverse proxy vérifié. Sans cette précaution, un client pourrait forger un X-Forwarded-For et contourner la limitation de débit. Quand l'IP reste inconnue, la limitation est suspendue et un avertissement est émis une fois.

La valeur doit correspondre au nombre exact de proxys traversés : true ou 1 derrière un seul proxy, 2 derrière Cloudflare puis nginx. Le core lit dans X-Forwarded-For l'entrée située à ce rang en partant de la droite, la seule que le client ne peut pas écrire. Toute autre valeur qu'un entier positif ou true laisse les en-têtes ignorés. Voir Rate limit.

Base de données

L'ordre de résolution TLS est détaillé dans Base de données.

Les paramètres TLS portés par l'URL de connexion, ?sslmode=… en tête, sont retirés avant la connexion : ces trois variables restent la source de vérité. Le sslmode sert de valeur par défaut quand aucune n'est posée. Voir Paramètres TLS dans l'URL.

Chiffrement

Sur un projet monté à la main, générer la clé :

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

Changer cette clé rend illisible tout ce qui a été chiffré avec l'ancienne. Voir Chiffrement.

Stockage

Un seul jeu de variables sert les deux providers.

Courriel

Les variables LRVO_EMAIL_FROM_* et LRVO_EMAIL_LOGO* servent les deux fournisseurs. Le fournisseur actif est choisi par LRVO_EMAIL_PROVIDER, et seules les variables de ce fournisseur sont lues.

Paiements

isEnabled() retourne false tant que les deux premières ne sont pas définies, ce qui permet de masquer l'UI de paiement plutôt que de laisser un appel échouer.

Authentification

SEO

Admin

C'est la seule variable du core à trois états. Sa lecture teste === 'true' puis === 'false', et toute autre valeur laisse la détection automatique décider : sans @lrvo/module-pages ni @lrvo/module-posts, le projet n'a pas de site public et le bouton reste masqué. Voir features/admin.

Développement

Le devkit n'est jamais rendu quand le flag est absent ou différent de true.

Mises à jour et compatibilité

Le rappel de mise à jour est déjà muet hors terminal interactif et quand CI est définie : la variable ne sert qu'à l'éteindre sur un poste de développement. Voir lrvo-update.

La tuile update du tableau de bord lit la même variable, mais elle n'a aucune de ces gardes : elle tourne précisément là où il n'y a pas de terminal. C'est donc le seul moyen d'empêcher le serveur de contacter le registre. Voir features/admin.

LRVO_UPDATE_CHECK est la seule variable du core dont le défaut est actif. Sa lecture teste donc !== 'false', à l'inverse de LRVO_DEVKIT ou LRVO_SEO qui testent === 'true' : un projet dont le .env ne porte pas encore la variable garde le comportement par défaut.

LRVO_COMPAT_STRICT ne change rien au comportement par défaut, qui reste d'avertir. Un core sous le plancher exigé par un module fait échouer le boot dans les deux cas : cette combinaison est réellement inexécutable.

Variables d'un module

Chaque module @lrvo/module-* déclare ses propres variables dans manifest.envVars. Leur effet est documenté module par module : Pages, Posts, Médias, Formulaires, Facturation, Fichiers. Une variable required: true absente produit un avertissement au boot, sans faire tomber le serveur : le module gère son propre repli. lrvo-doctor, lui, la signale comme bloquante ; il reste muet sur les optionnelles absentes, dont la valeur par défaut suffit.

Un module porte en plus une variable d'activation de la forme LRVO_MODULE_<NOM>. Installé mais non activé, il n'enregistre rien.

LRVO_MODULE_MEDIAS=true