@eqs/tooling publiait un paquet amputé #45

Merged

nicolas-fryder merged 1 commit from fix/tooling-scripts-publies into main

2026-09-10 06:57:10 +00:00

nicolas-fryder commented

2026-09-10 06:57:05 +00:00

Owner

conformite.js importait ./scripts/workspaces-dockerfile.js, absent du
champ files. Chez le consommateur, l'import de tête échouait et TOUS les
contrôles du paquet disparaissaient — pas seulement le nouveau. Un satellite
en 0.8.0 perdait une partie de sa porte en lisant « Aucun problème
statique ».

Le module publié vit désormais à la racine du paquet, avec orval.js et
conformite.js. Publier scripts/ entier aurait embarqué le vérificateur
de pnpm check, qui n'a rien à faire chez un consommateur.

La barrière qui manquait : le check vérifiait que chaque export existe
dans l'ARBRE DE TRAVAIL, où tout est toujours là. Il éprouve maintenant ce
que npm pack emporte, et importe chaque point d'entrée depuis le tarball
extrait. C'est ce qui distingue « le code marche » de « le paquet publié
marche », et c'était exactement l'écart.

Vérifié dans les deux sens : vert tel quel, rouge dès qu'on retire le
fichier du champ files.

Le bac est déballé DANS le package, pour que node_modules se résolve en
remontant : hors du dépôt, l'import échouait sur typescript-eslint et non
sur le fichier manquant — un faux positif qui aurait fait désactiver la
vérification.

eqs doctor ne dit plus « Aucun problème statique » quand un paquet n'a pas
pu se charger. On ne sait pas ce qu'on ne voit pas.

Signalé par le premier satellite réel (#44), qui a refusé de contourner en
ajoutant le fichier à la main dans node_modules — et il a eu raison.

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

`conformite.js` importait `./scripts/workspaces-dockerfile.js`, absent du champ `files`. Chez le consommateur, l'import de tête échouait et TOUS les contrôles du paquet disparaissaient — pas seulement le nouveau. Un satellite en 0.8.0 perdait une partie de sa porte en lisant « Aucun problème statique ». Le module publié vit désormais à la racine du paquet, avec `orval.js` et `conformite.js`. Publier `scripts/` entier aurait embarqué le vérificateur de `pnpm check`, qui n'a rien à faire chez un consommateur. La barrière qui manquait : le `check` vérifiait que chaque export existe dans l'ARBRE DE TRAVAIL, où tout est toujours là. Il éprouve maintenant ce que `npm pack` emporte, et importe chaque point d'entrée depuis le tarball extrait. C'est ce qui distingue « le code marche » de « le paquet publié marche », et c'était exactement l'écart. Vérifié dans les deux sens : vert tel quel, rouge dès qu'on retire le fichier du champ `files`. Le bac est déballé DANS le package, pour que `node_modules` se résolve en remontant : hors du dépôt, l'import échouait sur `typescript-eslint` et non sur le fichier manquant — un faux positif qui aurait fait désactiver la vérification. `eqs doctor` ne dit plus « Aucun problème statique » quand un paquet n'a pas pu se charger. On ne sait pas ce qu'on ne voit pas. Signalé par le premier satellite réel (#44), qui a refusé de contourner en ajoutant le fichier à la main dans node_modules — et il a eu raison. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

nicolas-fryder added 1 commit

2026-09-10 06:57:05 +00:00

@eqs/tooling publiait un paquet amputé 2facdd5920

`conformite.js` importait `./scripts/workspaces-dockerfile.js`, absent du
champ `files`. Chez le consommateur, l'import de tête échouait et TOUS les
contrôles du paquet disparaissaient — pas seulement le nouveau. Un satellite
en 0.8.0 perdait une partie de sa porte en lisant « Aucun problème
statique ».

Le module publié vit désormais à la racine du paquet, avec `orval.js` et
`conformite.js`. Publier `scripts/` entier aurait embarqué le vérificateur
de `pnpm check`, qui n'a rien à faire chez un consommateur.

La barrière qui manquait : le `check` vérifiait que chaque export existe
dans l'ARBRE DE TRAVAIL, où tout est toujours là. Il éprouve maintenant ce
que `npm pack` emporte, et importe chaque point d'entrée depuis le tarball
extrait. C'est ce qui distingue « le code marche » de « le paquet publié
marche », et c'était exactement l'écart.

Vérifié dans les deux sens : vert tel quel, rouge dès qu'on retire le
fichier du champ `files`.

Le bac est déballé DANS le package, pour que `node_modules` se résolve en
remontant : hors du dépôt, l'import échouait sur `typescript-eslint` et non
sur le fichier manquant — un faux positif qui aurait fait désactiver la
vérification.

`eqs doctor` ne dit plus « Aucun problème statique » quand un paquet n'a pas
pu se charger. On ne sait pas ce qu'on ne voit pas.

Signalé par le premier satellite réel (#44), qui a refusé de contourner en
ajoutant le fichier à la main dans node_modules — et il a eu raison.

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

nicolas-fryder merged commit 490d503513 into main

2026-09-10 06:57:10 +00:00

nicolas-fryder deleted branch fix/tooling-scripts-publies

2026-09-10 06:57:10 +00:00

nicolas-fryder referenced this pull request from a commit

2026-09-10 06:57:11 +00:00

Merge pull request '@eqs/tooling publiait un paquet amputé' (#45) from fix/tooling-scripts-publies into main