## Contexte

Nuxt Content alimente une collection depuis un dépôt git, sur une branche ou un
tag, s’authentifie auprès d’un dépôt privé et met le téléchargement en cache par
hachage. Cela a été vérifié en lisant Content lui-même avant que quoi que ce soit
d’ici ne soit construit, et cela signifie que la moitié difficile d’une
documentation multi-dépôts et versionnée existait déjà et n’avait pas besoin
d’être refaite.

Ce qui n’existait pas, c’était l’ergonomie. Un site servant plusieurs versions de
plusieurs projets déclare une collection par dépôt × ref, à la main : trois
versions sur quatorze dépôts font quarante-deux déclarations, et couper une
version les édite toutes les quatorze. Content n’offre pas non plus de hook pour
injecter des collections — mais il charge la configuration content de chaque
couche par c12, ce qui veut dire que ce fichier est du code exécuté et non un
fichier de données, et qu’il peut calculer ses collections au moment où il est
chargé.

## Décision

Les consommateurs déclarent une **liste de sources** compacte — un dossier,
éventuellement un dépôt, éventuellement des refs — dans l’app config du site
lui-même, et la configuration content de la couche en calcule une collection par
source × ref au chargement. La même liste est résolue une seconde fois par la
compilation, en un manifeste nommant quelle collection sert quel préfixe d’URL,
et c’est ce manifeste que le thème lit.

## Conséquences

La liste a la longueur du nombre de projets plutôt que celle du produit des
projets par les versions, et le dossier unique non versionné ne demande aucune
configuration du tout.

Le raccourci exprime moins qu’une collection écrite à la main, et ce sera
toujours le cas. Ce n’est supportable que parce que Content fusionne la
configuration content de chaque couche, la dernière l’emportant : un consommateur
qui a besoin de ce que le raccourci ne sait pas dire écrit son propre fichier et
reprend la main complètement.

Plusieurs fonctionnalités cessent d’avoir besoin de leur propre configuration,
parce qu’une source nomme déjà un dépôt, une ref et un dossier — les liens de
retour vers la source, la date de dernière mise à jour et la liste des
contributeurs en découlent tous.

Les noms de collection deviennent des données. Un site à deux dépôts n’a pas de
collection appelée `docs` : rien dans la couche ne peut donc en nommer une, et le
thème lit le nom dans le manifeste à la place. Du code qui code en dur un nom de
collection fonctionne sur un site à source unique et casse sur tous les autres.

Les chemins des collections se résolvent par rapport à la couche et non au
consommateur, parce que Content enregistre comme racine d’une collection la
couche qui l’a déclarée. La couche calcule donc des chemins absolus, ce qui n’est
possible que parce que la configuration est du code exécuté — la propriété même
sur laquelle repose tout le raccourci.