better-review 0.2.0 → 0.4.0

package/README.md

@@ -71,10 +71,14 @@ sans changer l'ordre).
 | Arbre | Dossiers repliables (sous-dossiers avant fichiers, A→Z ou Taille) avec changements, fichiers vus, threads      |
 | Liens | Fichiers en ordre de lecture « base d'abord », nombre d'imports / d'utilisateurs, graphe plein écran           |
 
-Les liens sont calculés côté serveur sur le contenu complet des fichiers au head de la PR : AST TypeScript pour
-TS/JS (y compris `.js` → `.ts`, `require`, `import()`), règles dédiées pour Python, CSS/SCSS/Less, Go, Java/Kotlin,
-C/C++, Rust, Ruby, Vue/Svelte. Les mentions (nom de fichier en CamelCase, ou nom avec extension, ou chemin) couvrent
-la doc et les autres langages. Les alias `tsconfig` `paths` autres que `@/`, `~/`, `#` ne sont pas résolus.
+**Langages pris en charge** : TypeScript / JavaScript, HTML, CSS / SCSS / Sass / Less, Markdown, JSON et texte brut
+(`.txt`). Seuls les fichiers de ces langages sont analysés et colorés ; les autres s'affichent en texte simple et
+peuvent seulement être la cible d'un lien. Les liens sont calculés côté serveur sur le contenu complet des fichiers au
+head de la PR : AST TypeScript pour TS/JS (y compris `.js` → `.ts`, `require`, `import()`) ; `<script src>` et
+`<link href>` pour HTML (URL relatives, ou `/…` depuis le dossier de la page) ; `@import` / `@use` / `@forward` pour les
+feuilles de style (partiels `_x.scss`, `index`, chemins de chargement) ; les mentions (nom de fichier en CamelCase, ou
+nom avec extension, ou chemin) valent pour tous ces langages. Les alias `tsconfig` `paths` autres que `@/`, `~/`, `#`
+ne sont pas résolus.
 
 **Ordre « base d'abord »** (vue Liens) : ordre topologique, chaque fichier après ceux qu'il importe ou mentionne, les
 plus utilisés en premier, les cycles départagés de la même façon et les fichiers sans lien à la fin. On relit la PR de
@@ -83,12 +87,11 @@ ses fondations vers ce qui les assemble.
 **Voisinage** (onglet du panneau de droite, 520 px, quelle que soit la vue de gauche) : graphe du fichier courant, ce
 qu'il utilise → fichier → ce qui l'utilise, avec tous ses voisins ; clic sur un voisin pour l'ouvrir.
 
-**Monorepos** : chaque dossier contenant un manifeste (`package.json`, `pyproject.toml`, `setup.py`, `go.mod`,
-`Cargo.toml`, `pom.xml`, `build.gradle`, `composer.json`) est un package ; à partir de deux, l'ordre devient
+**Monorepos** : chaque dossier contenant un `package.json` est un package ; à partir de deux, l'ordre devient
 hiérarchique : packages du plus utilisé au plus dépendant (dépendances déclarées entre packages du workspace, y
 compris via un package non modifié, + imports entre fichiers), puis la base d'abord dans chaque package. Les imports
-par nom de package (`@acme/shared`, `@acme/shared/x`, crates Rust) sont résolus vers le point d'entrée du package
-(`exports` / `main` / `types` de `package.json`, sources `src/` correspondantes, `src/index.*`, `src/lib.rs`). La
+par nom de package (`@acme/shared`, `@acme/shared/x`) sont résolus vers le point d'entrée du package
+(`exports` / `main` / `types` de `package.json`, sources `src/` correspondantes, `src/index.*`). La
 vue Liens groupe les fichiers par package et le graphe plein écran les encadre ; il affiche aussi les autres packages du
 monorepo et les dépendances entre packages (option « Autres packages du monorepo ») : en couleur uniquement les
 packages qui contiennent des fichiers modifiés (et les liens entre eux), le reste en gris. Le graphe de voisinage
@@ -101,13 +104,30 @@ La description de la PR s'ouvre dans l'onglet « Description » du panneau de dr
 ## Architecture
 
 ```
-apps/cli        paquet npm `better-review` : serveur + packages du workspace groupés par esbuild, front compilé dans dist/web
-apps/server     Node + Hono + tRPC v11 : proxy GitHub (GraphQL, diffs REST), SQLite, polling → subscriptions SSE
-apps/web        Vite + React + Mantine, TanStack Router / Query, diff virtualisé, coloration Shiki en Web Worker
-packages/shared schémas zod, parseur de diff unifié (empreinte de hunk partagée serveur / navigateur)
+apps/cli                paquet npm `better-review` : serveur + packages du workspace groupés par esbuild, front dans dist/web
+apps/server             Node + Hono + tRPC v11 : proxy GitHub (GraphQL, diffs REST), SQLite, polling → subscriptions SSE
+apps/web                Vite + React + Mantine, TanStack Router / Query, diff virtualisé, coloration Shiki en Web Worker
+packages/shared         schémas zod, parseur de diff unifié (empreinte de hunk partagée serveur / navigateur)
+packages/language       briques communes aux langages : registre, chemins, index des fichiers, contrats d'analyse / coloration
+packages/lang-typescript TS / JS : imports (AST TypeScript), écosystème npm (package.json), grammaires Shiki
+packages/lang-html      HTML : `<script src>`, `<link href>`, grammaire Shiki
+packages/lang-css       CSS / SCSS / Sass / Less : `@import` / `@use` / `@forward` (résolution façon Sass), grammaires Shiki
+packages/lang-markdown  Markdown : mentions, grammaire Shiki
+packages/lang-json      JSON / JSONC : mentions, grammaires Shiki
+packages/lang-text      texte brut : mentions
 ```
 
+Chaque package de langage expose une partie `./analysis` (serveur : `LanguageAnalyzer`, et `Ecosystem` pour les
+manifestes) et une partie `./highlight` (navigateur : `LanguageHighlighter`, grammaires chargées à la demande). Ajouter
+un langage : créer `packages/lang-<nom>` sur ce modèle, puis l'enregistrer dans `apps/server/src/languages.ts` et
+`apps/web/src/highlight/languages.ts` (seuls points d'enregistrement).
+
 - Les diffs sont demandés entre deux SHA (immuables) et mis en cache définitivement.
+- La coloration syntaxique porte sur le fichier entier (blobs désignés par les lignes `index` du diff, mis en cache
+  définitivement) : un commentaire ou une chaîne ouvert hors d'un hunk est coloré correctement. Fichier trop gros ou
+  indisponible : seules les lignes du diff sont colorées.
+- Un commentaire, une réponse ou un nouveau thread s'affiche dès la réponse de GitHub ; la PR est rechargée ensuite en
+  arrière-plan.
 - L'inbox fait une recherche « ids seulement » par section puis charge chaque PR une seule fois
   (≈ 1 point de quota GraphQL par PR).
 - Une PR ouverte est surveillée toutes les 30 s, l'inbox toutes les 2 min ; un changement côté GitHub