DOCS_ACCESS est lue sur source mais absente de baseSchema : ni validée, ni vue par config.env-example #107

Closed
opened 2026-10-01 13:32:40 +00:00 by nicolas-fryder · 0 comments

Ce qui se passe

assemblage.js lit la variable directement sur la source brute :

source['DOCS_ACCESS'] === 'public' || source['DOCS_ACCESS'] === 'session'
  ? source['DOCS_ACCESS']
  : …

Elle n'est pas dans baseSchema. Trois conséquences :

  1. Aucune validation. DOCS_ACCESS=publlic (faute de frappe) retombe sur le défaut — session en production — et la documentation disparaît sans que rien ne le dise. C'est exactement ce que @eqs/config existe pour empêcher.
  2. config.env-example ne peut pas la connaître. Le contrôle compare .env.example au schéma ; une variable hors schéma est soit absente du contrôle, soit signalée « dans .env.example mais pas dans le schéma » si on essaie de la documenter. Un satellite ne peut donc pas l'écrire dans son .env.example sans faire échouer la porte.
  3. Elle contredit config.lecture-hors-module dans l'esprit : le satellite a un seul lecteur de process.env, et le socle en ajoute un second par-dessous.

Même remarque, plus bénigne, pour les clés de commit (GIT_COMMIT, SOURCE_COMMIT, COMMIT_SHA, VCS_REF, BUILT_AT) : elles sont injectées au build et non configurées, donc leur absence du schéma se défend mieux — mais elle mérite peut-être une phrase quelque part.

Proposition

Ajouter à baseSchema :

DOCS_ACCESS: z.enum(['public', 'session']).optional()

Le défaut reste calculé dans assemblage (session en production, public ailleurs) : l'enum ne sert qu'à refuser une valeur erronée et à rendre la variable visible aux contrôles. C'est additif, et cela rend DOCS_ACCESS=publlic bloquant au démarrage au lieu de silencieux.

Rencontré en rétrofittant nuage : SWAGGER_ENABLED était la variable maison équivalente, et en la retirant au profit de DOCS_ACCESS je me suis aperçu qu'il n'y avait nulle part où la déclarer.

Socle 0.14.0.

## Ce qui se passe `assemblage.js` lit la variable directement sur la source brute : ```js source['DOCS_ACCESS'] === 'public' || source['DOCS_ACCESS'] === 'session' ? source['DOCS_ACCESS'] : … ``` Elle n'est pas dans `baseSchema`. Trois conséquences : 1. **Aucune validation.** `DOCS_ACCESS=publlic` (faute de frappe) retombe sur le défaut — `session` en production — et la documentation disparaît sans que rien ne le dise. C'est exactement ce que `@eqs/config` existe pour empêcher. 2. **`config.env-example` ne peut pas la connaître.** Le contrôle compare `.env.example` au schéma ; une variable hors schéma est soit absente du contrôle, soit signalée « dans .env.example mais pas dans le schéma » si on essaie de la documenter. Un satellite ne peut donc pas l'écrire dans son `.env.example` sans faire échouer la porte. 3. **Elle contredit `config.lecture-hors-module`** dans l'esprit : le satellite a un seul lecteur de `process.env`, et le socle en ajoute un second par-dessous. Même remarque, plus bénigne, pour les clés de commit (`GIT_COMMIT`, `SOURCE_COMMIT`, `COMMIT_SHA`, `VCS_REF`, `BUILT_AT`) : elles sont injectées au build et non configurées, donc leur absence du schéma se défend mieux — mais elle mérite peut-être une phrase quelque part. ## Proposition Ajouter à `baseSchema` : ```ts DOCS_ACCESS: z.enum(['public', 'session']).optional() ``` Le défaut reste calculé dans `assemblage` (`session` en production, `public` ailleurs) : l'enum ne sert qu'à refuser une valeur erronée et à rendre la variable visible aux contrôles. C'est additif, et cela rend `DOCS_ACCESS=publlic` bloquant au démarrage au lieu de silencieux. Rencontré en rétrofittant nuage : `SWAGGER_ENABLED` était la variable maison équivalente, et en la retirant au profit de `DOCS_ACCESS` je me suis aperçu qu'il n'y avait nulle part où la déclarer. Socle 0.14.0.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-platform#107
No description provided.