D-041 : un satellite ne produit pas de package publiable #31

Closed

nicolas-fryder wants to merge 0 commits from docs/d-041-pas-de-package-en-satellite into main

nicolas-fryder commented

2026-09-09 16:11:38 +00:00

Owner

Enregistre la décision prise en triant les tickets du premier satellite.

La règle : s'il faut produire un package, il vit dans son propre dépôt, versionné et publié pour lui-même. packages/* sort donc du pnpm-workspace.yaml du gabarit, et le README l'énonce comme une règle et non comme une étape à franchir.

Ce n'est pas une restriction technique — pnpm sait très bien porter un package dans un satellite. C'est la conséquence de ce qui manquerait autour : un paquet enfoui dans un satellite n'a ni cible de construction, ni étape de publication dans sa CI, ni numéro de version qui lui soit propre, et personne ne saurait dire de quel dépôt il sort ni ce qui l'a éprouvé.

Du code partagé entre les deux applications d'un satellite nest reste possible : il vit dans celle qui le possède, et la seconde le consomme par son client généré, comme n'importe quel autre service (D-025).

Origine : eqs-satellite-template #7, qui s'inquiétait d'un Dockerfile énumérant apps/api/package.json et apps/web/package.json face à un plan de travail qui promettait packages/*. La divergence annoncée ne se reproduit pas (mesurée deux fois, commentée dans le Dockerfile du gabarit), mais la question sous-jacente était juste : la promesse était le défaut, pas l'énumération.

L'application côté gabarit est déjà partie (chore/pas-de-packages).

node scripts/check.mjs → 51 fichiers Markdown, 41 décisions, 0 problème.

🤖 Generated with Claude Code

Enregistre la décision prise en triant les tickets du premier satellite. **La règle** : s'il faut produire un package, il vit dans son *propre* dépôt, versionné et publié pour lui-même. `packages/*` sort donc du `pnpm-workspace.yaml` du gabarit, et le README l'énonce comme une règle et non comme une étape à franchir. Ce n'est pas une restriction technique — pnpm sait très bien porter un package dans un satellite. C'est la conséquence de ce qui manquerait autour : un paquet enfoui dans un satellite n'a ni cible de construction, ni étape de publication dans sa CI, ni numéro de version qui lui soit propre, et personne ne saurait dire de quel dépôt il sort ni ce qui l'a éprouvé. Du code partagé entre les **deux** applications d'un satellite `nest` reste possible : il vit dans celle qui le possède, et la seconde le consomme par son client généré, comme n'importe quel autre service (D-025). **Origine** : `eqs-satellite-template` #7, qui s'inquiétait d'un `Dockerfile` énumérant `apps/api/package.json` et `apps/web/package.json` face à un plan de travail qui promettait `packages/*`. La divergence annoncée ne se reproduit pas (mesurée deux fois, commentée dans le `Dockerfile` du gabarit), mais la question sous-jacente était juste : la promesse était le défaut, pas l'énumération. L'application côté gabarit est déjà partie (`chore/pas-de-packages`). `node scripts/check.mjs` → 51 fichiers Markdown, 41 décisions, 0 problème. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nicolas-fryder added 1 commit

2026-09-09 16:11:38 +00:00

D-041 : un satellite ne produit pas de package publiable 31cebf0423

Soulevé par le premier satellite réel (eqs-satellite-template #7), qui
butait sur un Dockerfile énumérant les manifestes face à un plan de
travail promettant `packages/*`. La promesse était le défaut.

S'il faut produire un package, il vit dans son propre dépôt : sinon il
n'a ni cible de construction, ni publication dans sa CI, ni version qui
lui soit propre, et personne ne sait ce qui l'a éprouvé.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

nicolas-fryder closed this pull request

2026-09-09 20:16:54 +00:00