knipSatellite() ne déclare aucun point d'entrée pour une application à la racine du dépôt (profil next-fullstack non déplacé vers apps/*, D-003) #83

Closed
opened 2026-09-21 08:08:31 +00:00 by nicolas-fryder · 0 comments

Ce qui ne va pas

@eqs/tooling/knip-satellite déduit les points d'entrée en lisant apps/*. Pour la racine (workspaces['.']), il ne déclare que .claude/*.mjs, orval.config.*, playwright.config.* et e2e/**/*.spec.ts, avec project: ['.claude/*.mjs'].

Or D-003 dit qu'une application existante n'est pas déplacée vers le gabarit : elle importe les packages et reste où elle est. ATLAS est dans ce cas — next.config.js, src/, prisma/, tests/ à la racine, un worker/ en membre de workspace. Avec knipSatellite(), aucun fichier de src/ n'entre dans le périmètre : knip ne voit ni fichier mort, ni dépendance inutile, ni binaire absent. Il rend vert sur du vide.

Reproduction

Sur un dépôt dont l'application est à la racine (next.config.js à côté de package.json, pas de dossier apps/), @eqs/tooling 0.12.1 :

// knip.ts
import { knipSatellite } from '@eqs/tooling/knip-satellite'
export default knipSatellite()
pnpm exec knip --no-progress --include files,dependencies,unlisted,unresolved,binaries

Obtenu : sortie 0, rien signalé — alors que le même dépôt, avec une configuration manuelle qui déclare src/** en project, signale un fichier réellement mort (worker/src/crawlers/communeData.ts, déconnecté depuis juin) et une devDependency inutilisée.

Attendu : knipSatellite() reconnaît une application à la racine (le marqueur next.config.* que eqs check utilise déjà pour décider d'un build:) et lui donne les mêmes entrées qu'à une apps/<x> : src/instrumentation.ts, scripts/*.mjs, test/** ou tests/**, prisma/seed.ts, prisma.config.ts, le eqs.openapi du manifeste.

Ce que ça coûte

Contournable : ATLAS écrit son knip.ts à la main en étendant @eqs/tooling/knip (la base des règles), ce qui marche. Mais c'est exactement le cas que le README de knipSatellite veut éviter — « du code copié dans trente satellites dérive » — et le mode d'échec est le pire : une porte verte qui ne regarde rien. Le prochain dépôt rétrofitté (photofront, metalfrom, nuage : tous à la racine) tombera dessus.

Ce que je proposerais

  1. Dans knipSatellite(), si next.config.* (ou src/main.ts) existe à la racine et qu'il n'y a pas d'apps/, traiter la racine comme une application : entreesDe(racine, '.') plus project: ['src/**', 'prisma/**', 'scripts/**', 'tests/**'].
  2. Dire dans le README de @eqs/tooling que la base @eqs/tooling/knip s'étend à la main quand la disposition n'est pas celle du gabarit — c'est ce qu'ATLAS fait aujourd'hui.

Versions

@eqs/tooling 0.12.1, @eqs/cli 0.12.1, knip 6.37.0, pnpm 11.8.0, Node 24.15.0, Windows 11. Contexte : rétrofit d'ATLAS, branche epic/retrofit de EQS/ATLAS, docs/retrofit-eqs.md (étape 1).

## Ce qui ne va pas `@eqs/tooling/knip-satellite` déduit les points d'entrée en lisant `apps/*`. Pour la racine (`workspaces['.']`), il ne déclare que `.claude/*.mjs`, `orval.config.*`, `playwright.config.*` et `e2e/**/*.spec.ts`, avec `project: ['.claude/*.mjs']`. Or D-003 dit qu'une application existante **n'est pas déplacée** vers le gabarit : elle importe les packages et reste où elle est. ATLAS est dans ce cas — `next.config.js`, `src/`, `prisma/`, `tests/` à la racine, un `worker/` en membre de workspace. Avec `knipSatellite()`, aucun fichier de `src/` n'entre dans le périmètre : knip ne voit ni fichier mort, ni dépendance inutile, ni binaire absent. Il rend vert sur du vide. ## Reproduction Sur un dépôt dont l'application est à la racine (`next.config.js` à côté de `package.json`, pas de dossier `apps/`), `@eqs/tooling` 0.12.1 : ```ts // knip.ts import { knipSatellite } from '@eqs/tooling/knip-satellite' export default knipSatellite() ``` ``` pnpm exec knip --no-progress --include files,dependencies,unlisted,unresolved,binaries ``` Obtenu : sortie 0, rien signalé — alors que le même dépôt, avec une configuration manuelle qui déclare `src/**` en `project`, signale un fichier réellement mort (`worker/src/crawlers/communeData.ts`, déconnecté depuis juin) et une devDependency inutilisée. Attendu : `knipSatellite()` reconnaît une application à la racine (le marqueur `next.config.*` que `eqs check` utilise déjà pour décider d'un `build:`) et lui donne les mêmes entrées qu'à une `apps/<x>` : `src/instrumentation.ts`, `scripts/*.mjs`, `test/**` ou `tests/**`, `prisma/seed.ts`, `prisma.config.ts`, le `eqs.openapi` du manifeste. ## Ce que ça coûte Contournable : ATLAS écrit son `knip.ts` à la main en étendant `@eqs/tooling/knip` (la base des règles), ce qui marche. Mais c'est exactement le cas que le README de `knipSatellite` veut éviter — « du code copié dans trente satellites dérive » — et le mode d'échec est le pire : une porte verte qui ne regarde rien. Le prochain dépôt rétrofitté (photofront, metalfrom, nuage : tous à la racine) tombera dessus. ## Ce que je proposerais 1. Dans `knipSatellite()`, si `next.config.*` (ou `src/main.ts`) existe à la racine et qu'il n'y a pas d'`apps/`, traiter la racine comme une application : `entreesDe(racine, '.')` plus `project: ['src/**', 'prisma/**', 'scripts/**', 'tests/**']`. 2. Dire dans le README de `@eqs/tooling` que la base `@eqs/tooling/knip` s'étend à la main quand la disposition n'est pas celle du gabarit — c'est ce qu'ATLAS fait aujourd'hui. ## Versions `@eqs/tooling` 0.12.1, `@eqs/cli` 0.12.1, knip 6.37.0, pnpm 11.8.0, Node 24.15.0, Windows 11. Contexte : rétrofit d'ATLAS, branche `epic/retrofit` de `EQS/ATLAS`, `docs/retrofit-eqs.md` (étape 1).
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#83
No description provided.