minimumReleaseAgeExclude rend toute commande pnpm dépendante du réseau, pas seulement l'installation : aucun satellite ne peut jouer sa porte hors ligne #66

Closed
opened 2026-09-13 04:25:04 +00:00 by nicolas-fryder · 0 comments

Ce qui ne va pas

pnpm-workspace.yaml du gabarit déclare, pour de bonnes raisons documentées juste au-dessus :

minimumReleaseAgeExclude:
  - '@eqs/*'

La machinerie de minimumReleaseAge de pnpm 11 s'active alors, et elle interroge le registre npm à chaque commande pnpm --filter … <script> — pas seulement à l'installation. Sans réseau, elle retente jusqu'à épuisement du délai avant que le script demandé ne s'exécute.

Conséquence : dans un satellite EQS, pnpm --filter api typecheck, pnpm --filter api lint, pnpm --filter api test — donc pnpm check, donc la porte du dépôt — ne peuvent pas s'exécuter sans accès au registre, alors qu'aucune de ces commandes n'installe quoi que ce soit.

Reproduction

Dans un clone provisionné (node_modules déjà installés), sans réseau :

docker run --rm --network none -v "$PWD:/travail" -w /travail node:22.18-alpine \
  sh -lc 'corepack enable && pnpm --filter api typecheck'

Obtenu : la commande n'atteint jamais tsc. Elle passe son temps à retenter l'interrogation du registre, puis meurt sur le délai de l'appelant.

Attendu : tsc s'exécute, puisque tout ce dont il a besoin est déjà sur le disque.

Reproduit indépendamment hors de notre contexte d'origine, pour écarter une particularité de notre outillage.

Ce que ça coûte

Le contexte : je construis, dans un satellite, un système où des agents écrivent du code et où une commande de terminaison décide si le travail est bon. Ces agents tournent dans un conteneur volontairement coupé du réseau — c'est la frontière d'isolation, et elle n'est pas négociable.

Une campagne de mesure a duré 4 h 47 au lieu de quelques minutes, chaque tour brûlant ses 600 s de délai dans des tentatives de connexion, et le verdict a été masqué sur sept tâches sur neuf. Deux tâches où le modèle avait produit un travail correct — vérifié ligne à ligne sur le disque — ont été comptées comme des échecs.

Au-delà de mon cas, ça touche tout usage hors ligne d'un satellite : une CI sans sortie réseau, une construction d'image Docker sans réseau, un développement dans un train. La porte du dépôt devient indisponible dans des situations où rien ne le laisse prévoir, et le symptôme — une commande lente qui finit par expirer — ne désigne pas sa cause.

Ce que je proposerais

Je ne sais pas si ce comportement de pnpm est intentionnel ou un défaut de pnpm lui-même ; je rapporte ce que j'observe, et la décision de la voie vous revient.

  1. Vérifier si minimumReleaseAge peut se limiter à l'installation. Si pnpm offre un réglage pour ça, c'est la réponse la plus propre : la protection garde tout son sens à l'install, où elle protège, et disparaît sur run, où elle ne protège de rien.
  2. Documenter le réglage qui la neutralise, quel qu'il soit, et dire dans le gabarit qu'un environnement hors ligne doit le poser. C'est le minimum : aujourd'hui rien n'annonce cette dépendance.
  3. L'appliquer dans les contextes de la flotte qui sont hors ligne par construction — les images Docker, et toute exécution isolée.
  4. Envisager un contrôle qui vérifie que pnpm check aboutit sans réseau. C'est une propriété qui se teste mécaniquement, et elle vaut pour les trente dépôts.

De mon côté, je neutralise la vérification dans l'environnement de mon conteneur d'agents, en le déclarant hors ligne — au même titre qu'il se déclare déjà non interactif. C'est local et assumé, et ça ne dispense pas de traiter la cause.

Versions

  • pnpm 11.8.0 (packageManager du gabarit), @eqs/* ^0.8.1.
  • Clone neuf, profil nest, constaté le 2026-09-13 sur Windows 11 / Docker Desktop, conteneur node:22.18-alpine.

Lien avec d'autres tickets

Même famille que #63 (db:dev attend une saisie au clavier) : un outil qui suppose un environnement interactif ou connecté, dans un contexte qui n'est ni l'un ni l'autre. Un satellite est de plus en plus souvent exécuté par une machine — CI, conteneur, agent — et ces suppositions se paient à chaque fois.

## Ce qui ne va pas `pnpm-workspace.yaml` du gabarit déclare, pour de bonnes raisons documentées juste au-dessus : ```yaml minimumReleaseAgeExclude: - '@eqs/*' ``` La machinerie de `minimumReleaseAge` de pnpm 11 s'active alors, et elle **interroge le registre npm à chaque commande `pnpm --filter … <script>`** — pas seulement à l'installation. Sans réseau, elle retente jusqu'à épuisement du délai **avant** que le script demandé ne s'exécute. Conséquence : dans un satellite EQS, `pnpm --filter api typecheck`, `pnpm --filter api lint`, `pnpm --filter api test` — donc `pnpm check`, donc la porte du dépôt — **ne peuvent pas s'exécuter sans accès au registre**, alors qu'aucune de ces commandes n'installe quoi que ce soit. ## Reproduction Dans un clone provisionné (`node_modules` déjà installés), sans réseau : ```bash docker run --rm --network none -v "$PWD:/travail" -w /travail node:22.18-alpine \ sh -lc 'corepack enable && pnpm --filter api typecheck' ``` Obtenu : la commande n'atteint jamais `tsc`. Elle passe son temps à retenter l'interrogation du registre, puis meurt sur le délai de l'appelant. Attendu : `tsc` s'exécute, puisque tout ce dont il a besoin est déjà sur le disque. Reproduit indépendamment hors de notre contexte d'origine, pour écarter une particularité de notre outillage. ## Ce que ça coûte Le contexte : je construis, dans un satellite, un système où des agents écrivent du code et où **une commande de terminaison décide** si le travail est bon. Ces agents tournent dans un conteneur volontairement coupé du réseau — c'est la frontière d'isolation, et elle n'est pas négociable. Une campagne de mesure a duré **4 h 47 au lieu de quelques minutes**, chaque tour brûlant ses 600 s de délai dans des tentatives de connexion, et le verdict a été masqué sur **sept tâches sur neuf**. Deux tâches où le modèle avait produit un travail correct — vérifié ligne à ligne sur le disque — ont été comptées comme des échecs. Au-delà de mon cas, ça touche tout usage hors ligne d'un satellite : une CI sans sortie réseau, une construction d'image Docker sans réseau, un développement dans un train. La porte du dépôt devient indisponible dans des situations où rien ne le laisse prévoir, et le symptôme — une commande lente qui finit par expirer — ne désigne pas sa cause. ## Ce que je proposerais Je ne sais pas si ce comportement de pnpm est intentionnel ou un défaut de pnpm lui-même ; je rapporte ce que j'observe, et la décision de la voie vous revient. 1. **Vérifier si `minimumReleaseAge` peut se limiter à l'installation.** Si pnpm offre un réglage pour ça, c'est la réponse la plus propre : la protection garde tout son sens à l'install, où elle protège, et disparaît sur `run`, où elle ne protège de rien. 2. **Documenter le réglage qui la neutralise**, quel qu'il soit, et dire dans le gabarit qu'un environnement hors ligne doit le poser. C'est le minimum : aujourd'hui rien n'annonce cette dépendance. 3. **L'appliquer dans les contextes de la flotte qui sont hors ligne par construction** — les images Docker, et toute exécution isolée. 4. **Envisager un contrôle** qui vérifie que `pnpm check` aboutit sans réseau. C'est une propriété qui se teste mécaniquement, et elle vaut pour les trente dépôts. De mon côté, je neutralise la vérification dans l'environnement de mon conteneur d'agents, en le déclarant hors ligne — au même titre qu'il se déclare déjà non interactif. C'est local et assumé, et ça ne dispense pas de traiter la cause. ## Versions - `pnpm` 11.8.0 (`packageManager` du gabarit), `@eqs/*` `^0.8.1`. - Clone neuf, profil `nest`, constaté le 2026-09-13 sur Windows 11 / Docker Desktop, conteneur `node:22.18-alpine`. ## Lien avec d'autres tickets Même famille que **#63** (`db:dev` attend une saisie au clavier) : un outil qui suppose un environnement interactif ou connecté, dans un contexte qui n'est ni l'un ni l'autre. Un satellite est de plus en plus souvent exécuté par une machine — CI, conteneur, agent — et ces suppositions se paient à chaque fois.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-platform#66
No description provided.