Référence du loader

@menestrel/astro fournit un loader Content Layer. Chaque collection le déclare dans src/content.config.ts.

import { defineCollection } from 'astro:content';
import { menestrelLoader } from '@menestrel/astro';

export const collections = {
  services: defineCollection({ loader: menestrelLoader({ collection: 'services' }) }),
  coordonnees: defineCollection({ loader: menestrelLoader({ collection: 'coordonnees' }) }),
};

Options

Option	Type	Description
collection	string	La clé de la collection ou du singleton, telle que définie dans le schéma. Obligatoire.

Résolution du contenu

Le loader résout un snapshot dans un ordre strict, sans bascule silencieuse. La reproductibilité du build prime sur la débrouillardise.

1. MENESTREL_OFFLINE=1 : lit .menestrel/snapshot/, produit par menestrel pull. Aucun réseau. C’est le mode des builds hermétiques et des démos.
2. MENESTREL_CONTENT_URL : lit le snapshot publié à cette URL. C’est le mode nominal en production : le build passe même si l’application est éteinte. La variable accepte une liste ordonnée, la deuxième valeur sert de repli si la première est en panne.
3. MENESTREL_TOKEN : interroge l’API pour découvrir le dernier snapshot publié. Pratique au démarrage, à réserver au développement.

Si aucun mode n’aboutit et que rien n’a jamais été publié, le build échoue avec un message explicite : un site vide en silence est pire qu’un build rouge. La porte de sortie (menestrel pull --demo, mode hors-ligne) est dans le message.

Ids d’entrées

• Collection : `${locale}/${slug}`, par exemple fr/stores-bannes. Lisible dans getStaticPaths, stable tant que le slug ne change pas.
• Singleton : `${locale}`, par exemple fr.

Chaque entrée expose data.locale et data.translations, qui ne liste que les locales réellement publiées.

Relations

Les relations sont réécrites en ids de store de la même locale. getEntry('services', entry.data.relation) fonctionne sans helper. Une cible dépubliée est omise avec un avertissement pour une relation simple, filtrée de la liste pour une relation multiple.

Build incrémental

Un second astro build sur le même snapshot ne recharge rien : le loader compare le snapshotId et les digests par entrée. Un nouveau snapshot ne re-télécharge que les entrées dont le digest a changé, et retire du store celles qui ont disparu.