[liogi]

gwt sync-env recopiait des fichiers versionnés par-dessus la branche.

Le défaut

L'exclusion se faisait par nom exact :

const EXCLUDED_FILES = new Set([
  ".env.test", ".env.example", ".env.tpl", ".env.template", ".env.sample",
]);

Donc .env.tpl était protégé, mais .env.development.tpl non — et c'est la forme que les vrais dépôts utilisent. Ces fichiers sont suivis par git : leur contenu appartient à la branche. Recopier la version du worktree principal par-dessus une branche qui vient d'en modifier un produit un git status que personne n'a demandé.

Sur un monorepo qui nomme ses gabarits par environnement, ça fait 44 fichiers concernés.

Le correctif

Vérification sur le suffixe, plus sur le nom :

fichier	avant	après
.env, .env.local, .env.development	copié	copié
.env.tpl, .env.example, .env.test	exclu	exclu
.env.development.tpl	copié	exclu
.env.production.tpl	copié	exclu
.env.development.local.tpl	copié	exclu
.env.development.example	copié	exclu
.env.test.local	copié	copié

Quatre lignes changent de comportement, et .env.test.local garde le sien : c'est une surcharge locale, pas un gabarit versionné.

Le test assertait la liste, pas la propriété

C'est ce qui a laissé passer le défaut :

assert.deepEqual(names, [".env", ".env.local"]);

Les cinq noms exacts passaient, donc le test était vert — alors que la propriété visée est « un fichier versionné n'est jamais recopié », et .env.development.tpl la viole par n'importe quel jugement, y compris celui de git. Le test couvre maintenant les formes préfixées ; réintroduire l'ancien filtre le fait échouer.

Internal

actions/checkout et actions/setup-node passent de v4 à v7 — fin de l'avertissement de dépréciation Node 20 sur les runners.

Détail utile pour la suite : setup-node v7 supprime le dummy NODE_AUTH_TOKEN export, précisément ce qui faisait renvoyer E401 à registry-url face au trusted publisher npm. Le contournement (ne pas mettre registry-url) n'est donc plus porteur — il reste en place, le chemin de publication fonctionne.

Et le taux de collision des couleurs est 8,8 %, mesuré sur 20 000 tirages. Le code disait huit pour cent à un endroit et une sur quatorze à un autre ; l'entrée 0.8.3 dit sept. Le premier était le plus proche. Les commentaires et le test portent maintenant le chiffre mesuré.

---

Et la liste de suffixes reste une supposition

Question posée en revue : « c'est générique ? quelqu'un d'autre a peut-être un système différent ». Elle est juste.

Un dépôt qui versionne .env.defaults — aucun suffixe de gabarit — avait le même bug sous une autre forme. La règle que la liste approximait est plus simple, et ne demande aucune configuration :

Le contenu d'un fichier suivi par git appartient à la branche. On ne l'écrase jamais.

planEnvSync marque donc tracked tout fichier que git suit dans la destination — c'est là qu'un diff parasite apparaîtrait — et sync-env annonce combien il a laissés. Les suffixes restent par-dessus, parce qu'ils portent une intention que l'index ne connaît pas : un .env.example non versionné reste un exemple.

Un piège mesuré

La consultation est un git ls-files scopé par pathspec. Délibérément : un listing nu sort 1,09 Mo sur un gros monorepo, au-dessus du maxBuffer par défaut d'execFileSync — contre 1,7 Ko scopé. La version naïve échouait sur le dépôt qui a révélé le bug.

Vérifié, pas déduit

Sur le monorepo concerné, 68 fichiers .env* : 40 suivis par git → tous exclus, 28 non suivis → tous copiés. Zéro du mauvais côté, dans les deux sens. Un sync-env --all en dry-run annonce 112 fichiers sur 4 worktrees, soit 28 chacun, et pas un .tpl.

Et les deux nouveaux tests échouent si on retire la garde — vérifié en neutralisant l'appel dans le build :

not ok 4 - a file git tracks in the destination is never copied

165 tests.