reusable-ci-node: knip lance en pnpm dlx ne resout pas les configs de plugins, et rend 31 faux positifs au lieu d'echouer

[BryanFRD]

L'étape knip de reusable-ci-node.yml est invoquée en pnpm dlx, ce qui la coupe des dépendances qu'elle doit pourtant charger. Quand elle échoue, elle ne signale pas une erreur de configuration : elle déclare le projet entier inutilisé et fait échouer le job.

Ce qui se passe

Le job installe d'abord les dépendances du paquet visé :

pnpm install --frozen-lockfile --filter @ferrfleet/site...

puis lance :

pnpm dlx knip --reporter compact

pnpm dlx récupère knip dans un magasin temporaire, isolé du node_modules qui vient d'être installé. knip détecte alors site/vite.config.ts via son plugin Vite et tente de le charger. Or ce fichier commence par :

import { defineConfig } from 'vite';

vite n'est pas résolvable depuis le contexte dlx, d'où :

ERROR: Error loading site/vite.config.ts (Cannot find module 'vite')
ERROR: Please fix or visit https://knip.dev/reference/known-issues
Unused files (31)
Unused dependencies (1)
##[error]Process completed with exit code 1.

Le vrai problème n'est pas l'erreur, c'est ce qu'elle devient

knip n'arrête pas sur l'erreur de résolution. Il continue avec une vue amputée du graphe, ne retrouve plus les points d'entrée, et conclut que 31 fichiers et une dépendance ne servent à rien. Le job échoue donc sur un rapport entièrement faux, dont rien dans le résumé ne dit qu'il découle d'un échec de chargement.

Quelqu'un qui lit « Unused files (31) » sans dérouler le log conclut que sa PR a cassé quelque chose. C'est ce qui m'est arrivé : j'ai d'abord cru à un problème de code avant de remonter à la ligne d'erreur au-dessus.

Ce que ça coûte

FerrFleet-Cloud#738 est une PR exclusivement Rust, trois fichiers dans api/src. Elle a été bloquée par ce job, sur un dépôt dont main est vert.

Point que je ne sais pas expliquer

L'échec est intermittent : le même job, relancé sans changement de code, est passé à la troisième tentative. Je n'ai pas d'explication solide, peut-être un état de cache dlx qui rend parfois vite résolvable. Je le signale plutôt que d'inventer une cause, mais l'intermittence rend le diagnostic plus difficile, pas moins grave : elle transforme un défaut de configuration en échec aléatoire.

Pistes de correction

Deux directions, à arbitrer :

• Invoquer knip depuis le workspace plutôt qu'en dlx, par exemple en le déclarant en devDependency et en passant par pnpm exec knip. Les fichiers de configuration des plugins deviennent alors résolvables, ce qui traite la cause.
• Faire échouer knip franchement sur une erreur de chargement, au lieu de poursuivre avec un graphe incomplet. Un rapport « inutilisé » calculé sur une configuration non chargée ne devrait jamais servir de verdict.

La première suffit à débloquer. La seconde évite que le prochain défaut de résolution, quel qu'il soit, ressorte à nouveau en faux positifs plausibles.

Voir aussi #314 sur l'étape audit du même workflow, rencontrée sur la même PR.