knipSatellite() produit 34 indices de configuration qu'un satellite ne peut pas faire taire, et qui accusent SON fichier #101

Closed
opened 2026-09-30 18:39:51 +00:00 by nicolas-fryder · 0 comments

Ce qui se passe

Sur nuage, avec un knip.ts qui suit exactement le README — knipSatellite() puis des ajouts après l'appel — pnpm knip sort sans aucun signalement et avec 34 indices de configuration :

$ pnpm knip
Configuration hints (34)
**/dist/**                            knip.ts  Remove from ignore
**/.next/**                           knip.ts  Remove from ignore
variantes/**                          knip.ts  Remove from ignore
**/prisma/**                          knip.ts  Remove from ignore
@eqs/tooling                          knip.ts  Remove from ignoreDependencies
.claude/*.mjs                         knip.ts  Refine entry pattern (no matches)
orval.config.*                        knip.ts  Refine entry pattern (no matches)
generated/**/*.ts         apps/front  knip.ts  Refine entry pattern (no matches)
src/main.ts               apps/front  knip.ts  Refine entry pattern (no matches)
src/instrumentation.ts    apps/front  knip.ts  Refine entry pattern (no matches)
scripts/*.mjs             apps/front  knip.ts  Refine entry pattern (no matches)
…

Les quinze motifs distincts viennent tous de knipSatellite(). Vérifié : aucun ne vient des ajouts du dépôt.

Pourquoi c'est gênant

Trois raisons, dans l'ordre où elles coûtent :

  1. La colonne dit knip.ts, c'est-à-dire le fichier du satellite. Quelqu'un qui lit la sortie va ouvrir son fichier et n'y trouvera rien de ce qui est reproché — les motifs sont dans la base, à laquelle il n'a pas accès depuis là.
  2. Le README interdit de les retirer : « ajouter une entrée propre à ce dépôt APRÈS l'appel plutôt que de réécrire la configuration : c'est ce qui garde la base propageable ». Réécrire pour faire taire les indices, c'est perdre les montées du socle.
  3. 34 lignes de bruit par exécution sur une commande dont toute la valeur tient à ce qu'on lise sa sortie. C'est l'argument que le socle fait lui-même à propos de knip : « un outil de code mort qui crie sur du code vivant se fait éteindre une fois, et plus personne ne le rallume ». Ici il ne crie pas sur du code vivant, il crie sur rien — le résultat est le même.

src/main.ts et src/instrumentation.ts appliqués à apps/front, ou .claude/*.mjs et orval.config.* à un dépôt qui n'en a pas, sont des motifs déduits de la forme du gabarit. C'est encore la famille de #83 et #100 : ce qui est déduit du moule ne vaut pas pour un dépôt que D-003 laisse où il est.

Ce que je proposerais

Le plus simple d'abord : ne poser un motif que s'il a une chance de matcher. knipSatellite() lit déjà le disque pour déduire — il peut filtrer ses propres motifs sur ce qui existe. src/main.ts n'a rien à faire dans les entry d'un apps/front, et orval.config.* n'a rien à faire dans un dépôt sans Orval.

À défaut, knip 6 permet d'abaisser les indices par rules ; mais les taire est moins bien que ne pas les produire — un indice juste, un jour, se perdrait dans les trente-trois autres.

Ce qui n'est PAS demandé

Les ignore de la base (**/dist/**, **/.next/**, **/prisma/**, variantes/**) sont légitimes même quand ils ne matchent pas : ils protègent le jour où le dossier apparaît. C'est knip qui les signale comme superflus, et le socle a raison de les garder. Ceux-là gagneraient juste à ne pas être comptés comme des indices — ou la base à les poser conditionnellement, comme les entry.

Versions

@eqs/tooling 0.14.0, knip 6.38.0, Node 24.15.0, pnpm 11.8.0. Mesuré le 2026-09-30 sur EQS-Sandbox/NUAGE, branche retrofit-socle-eqs, profil nest.

Contournement

Aucun : on lit les 34 lignes et on passe. Le dépôt n'a rien à retirer le jour où la base filtrera ses motifs.

## Ce qui se passe Sur `nuage`, avec un `knip.ts` qui suit exactement le README — `knipSatellite()` puis des ajouts après l'appel — `pnpm knip` sort **sans aucun signalement** et avec **34 indices de configuration** : ``` $ pnpm knip Configuration hints (34) **/dist/** knip.ts Remove from ignore **/.next/** knip.ts Remove from ignore variantes/** knip.ts Remove from ignore **/prisma/** knip.ts Remove from ignore @eqs/tooling knip.ts Remove from ignoreDependencies .claude/*.mjs knip.ts Refine entry pattern (no matches) orval.config.* knip.ts Refine entry pattern (no matches) generated/**/*.ts apps/front knip.ts Refine entry pattern (no matches) src/main.ts apps/front knip.ts Refine entry pattern (no matches) src/instrumentation.ts apps/front knip.ts Refine entry pattern (no matches) scripts/*.mjs apps/front knip.ts Refine entry pattern (no matches) … ``` Les quinze motifs distincts viennent **tous** de `knipSatellite()`. Vérifié : aucun ne vient des ajouts du dépôt. ## Pourquoi c'est gênant Trois raisons, dans l'ordre où elles coûtent : 1. **La colonne dit `knip.ts`**, c'est-à-dire le fichier du satellite. Quelqu'un qui lit la sortie va ouvrir son fichier et n'y trouvera rien de ce qui est reproché — les motifs sont dans la base, à laquelle il n'a pas accès depuis là. 2. **Le README interdit de les retirer** : « ajouter une entrée propre à ce dépôt APRÈS l'appel plutôt que de réécrire la configuration : c'est ce qui garde la base propageable ». Réécrire pour faire taire les indices, c'est perdre les montées du socle. 3. **34 lignes de bruit par exécution** sur une commande dont toute la valeur tient à ce qu'on lise sa sortie. C'est l'argument que le socle fait lui-même à propos de knip : « un outil de code mort qui crie sur du code vivant se fait éteindre une fois, et plus personne ne le rallume ». Ici il ne crie pas sur du code vivant, il crie sur rien — le résultat est le même. `src/main.ts` et `src/instrumentation.ts` appliqués à `apps/front`, ou `.claude/*.mjs` et `orval.config.*` à un dépôt qui n'en a pas, sont des motifs déduits de la forme du **gabarit**. C'est encore la famille de #83 et #100 : ce qui est déduit du moule ne vaut pas pour un dépôt que D-003 laisse où il est. ## Ce que je proposerais Le plus simple d'abord : **ne poser un motif que s'il a une chance de matcher.** `knipSatellite()` lit déjà le disque pour déduire — il peut filtrer ses propres motifs sur ce qui existe. `src/main.ts` n'a rien à faire dans les `entry` d'un `apps/front`, et `orval.config.*` n'a rien à faire dans un dépôt sans Orval. À défaut, knip 6 permet d'abaisser les indices par `rules` ; mais les taire est moins bien que ne pas les produire — un indice juste, un jour, se perdrait dans les trente-trois autres. ## Ce qui n'est PAS demandé Les `ignore` de la base (`**/dist/**`, `**/.next/**`, `**/prisma/**`, `variantes/**`) sont légitimes même quand ils ne matchent pas : ils protègent le jour où le dossier apparaît. C'est knip qui les signale comme superflus, et le socle a raison de les garder. Ceux-là gagneraient juste à ne pas être comptés comme des indices — ou la base à les poser conditionnellement, comme les `entry`. ## Versions `@eqs/tooling` 0.14.0, knip 6.38.0, Node 24.15.0, pnpm 11.8.0. Mesuré le 2026-09-30 sur `EQS-Sandbox/NUAGE`, branche `retrofit-socle-eqs`, profil `nest`. ## Contournement Aucun : on lit les 34 lignes et on passe. Le dépôt n'a rien à retirer le jour où la base filtrera ses motifs.
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#101
No description provided.