Git on vanityURLs

Editez custom, laissez defaults ennuyeux

Fri, 22 May 2026 00:00:00 +0000

La facon la plus rapide de ruiner un petit outil autohébergé est de modifier les fichiers upstream en place.

Cela fonctionne une fois. Puis la prochaine mise à jour pose une question ennuyeuse aux conséquences coûteuses : quels fichiers sont des defaults produit, quels fichiers sont des décisions locales, et quels fichiers sont une sortie générée?

vanityURLs évite cela avec trois couches :

Couche	Proprietaire	Regle
`defaults/` et `scripts/`	produit	rafraichir depuis upstream
`custom/`	instance	réviser et conserver
`build/` et `src/` génère	build	remplacer librement

Cette frontiere n’est pas de la bureaucratie. C’est ce qui empeche les mises à jour de devenir de l’archeologie.

Vous n'avez pas besoin de repartir de zéro

Fri, 22 May 2026 00:00:00 +0000

Quand un outil évolue rapidement, le reflexe tentant mais epuisant est de repartir de zero chaque fois que l’installateur s’améliore. Supprimer l’instance, cloner de nouveau, répondre aux questions, recopier les fichiers custom, puis esperer que rien de subtil n’a été perdu.

Ce n’est pas le workflow attendu avec vanityURLs.

Une instance est conçue pour garder son identité locale pendant que la couche produit s’améliore autour d’elle. Vos liens, horaires, politiques, marque, pages publiques, réglages Cloudflare et configuration des helpers vivent dans la couche de l’instance. Les fichiers produit upstream vivent dans defaults/ et scripts/. La sortie générée peut être reconstruite.