origam 2.21.0 → 2.23.0

package/CHANGELOG.md

@@ -18,6 +18,101 @@ This project follows [Semantic Versioning](https://semver.org).
 
 ## [Unreleased]
 
+## [2.23.0] - 2026-10-08
+
+### Added — `createOrigam({ code: { highlighter } })` : l'application fournit son highlighter
+
+`OrigamCode` importait `shiki` par un **specificateur nu** que le navigateur ne sait pas resoudre. Mesure sur le build de production d'une application consommatrice, avec 2.21.0 : `Failed to resolve module specifier 'shiki'`, blocs de code non colorises, et un bloc `yaml` rendu **vide**. Declarer `shiki` en dependance de l'application ne suffisait pas.
+
+⛔ **Le `@vite-ignore` n'etait pas une negligence** : sans lui, Rollup suit le graphe jusqu'au chargeur WASM de shiki et emet un chunk virtuel invalide (`default` est un mot reserve, esbuild rejette). Le retirer aurait casse `packages/docs` (VitePress). L'option contourne les deux : si l'application fournit un highlighter, **le DS ne touche jamais a `shiki`** dans ce chemin — plus d'import, plus de specificateur nu, plus de chunk WASM.
+
+`TShikiModule` n'exige que **`createHighlighter`**, pas la surface entiere de `shiki` : un module allege bati sur `shiki/core` + moteur regex JS fonctionne, et c'est ce qui evite la cause racine du contournement. Mesure du consommateur : **+65 Ko gzip contre +417 Ko** avec shiki complet.
+
+⚠️ **Non cassant** : sans l'option, le chemin par defaut est inchange ; `packages/docs` compile **sans aucune modification de sa part** (verifie, `exit 0`). Et le rattrapage vers le texte brut sur une langue non embarquee est **conserve deliberement** — c'est ce qui rend un highlighter partiel utilisable sans que la page casse.
+
+### Changed — ⚠️ RUPTURE : `IVariantProps` scinde en `IActionVariantProps` / `IInputVariantProps`
+
+**14 composants acceptaient des valeurs de `variant` qui ne faisaient rien.** `IVariantProps` etait un mixin **partage** entre composants d'action et de saisie, exposant l'union des deux vocabulaires (10 valeurs) alors que chaque famille n'en implemente que la moitie. Mesure en navigateur reel, avec contrôle positif :
+
+| famille | implemente | **inerte** |
+|---|---|---|
+| `OrigamBtn`, `OrigamBtnGroup`, `OrigamBtnToggle` | les 7 de `VARIANT` | **`underlined` `filled` `solo`** — byte-identiques a `flat` sur les 7 longhands |
+| `OrigamField` + 9 descendants | les 5 de `VARIANT_INPUT` | **`text` `flat` `elevated` `tonal` `ghost`** — identiques entre eux |
+
+`useVariant()` emet bien la classe `--variant-{valeur}` — il n'a aucune liste blanche — mais **aucune regle CSS ne la cible**.
+
+⚠️ **`outlined` et `plain` sont implementes des DEUX cotes**, avec un rendu different selon le composant. Ce chevauchement est **legitime** (deux patterns UI distincts partageant un nom) et ne change pas. Le defaut etait l'asymetrie, pas le recouvrement.
+
+**`IVariantProps` est SUPPRIME** — mesure : zero consommateur hors des 14 composants, de son composable et de son test. `OrigamConfirmWrapper` recoit `IInputVariantProps` : son `variant` n'est qu'un defaut pousse vers les champs qu'il enveloppe.
+
+**Ce que la restriction a revele** : `OrigamConfirmWrapper.story.vue` proposait `VARIANT_OPTIONS` (les 7 valeurs d'action) alors que ce composant pousse des defauts vers des **champs de formulaire** — faux en silence depuis la creation de la story.
+
+**Cout de la rupture, mesure** : un consommateur qui passe `variant="solo"` a un `OrigamBtn` n'obtient **rien** aujourd'hui. La restriction transforme un silence en erreur de compilation, ce qui l'informe. La seule application cliente connue a audite ses deux etats : **zero occurrence**, et `git grep IVariantProps` y rend **0**.
+
+Epingle par `packages/tests/TU/playground/variant-literal-union.spec.ts`, verifie **ROUGE sur le commit parent** (10/10) et **VERT apres** (7 et 5) — sur le descripteur resolu, pas sur le texte source.
+
+### Fixed — un test unitaire reconstruisait deux fois le programme TypeScript entier
+
+`extractLiteralUnions()` appelle `createChecker()`, qui rebatit tout le programme de `packages/ds/tsconfig.json` depuis zero a chaque appel. Le test l'appelait **une fois par `it()`**, payant ce cout deux fois. Un seul appel partage dans un `beforeAll` suffit aux deux cas.
+
+⚠️ **Ce n'etait pas un defaut produit ni une particularite de Node 22**, et la mesure le montre : **3,73 s** isole, **54,6 s** sur le job CI Node 22 (un timeout), **36,0 s** sur le job Node 24 du **meme run** (vert, mais presque sans marge). Le facteur de 8 a 14 vient de la contention des workers Vitest sur un runner partage — Node 22 n'a pas cause l'echec, il l'a expose le premier.
+
+⚠️ **Ne figure pas dans le paquet publie** : le lot de fondation du playground (`packages/playground`, prive) n'affecte pas le tarball.
+
+## [2.22.0] - 2026-10-07
+
+### Added — `attach` sur `OrigamCommandPalette`, `OrigamSnackbarGroup` et `OrigamDrawer`
+
+Ces trois composants codaient en dur `<teleport to="body">` et n'offraient **aucun moyen de
+rediriger** la cible, alors que toute la famille Overlay — Tooltip, Snackbar, Dialog, Menu, via
+`IOverlayProps` — portait déjà `attach`. C'était une surface à moitié implémentée, et la directive
+d'`adr-007-directional-props.md` est explicite : *si un format existe, il existe partout ; on ne
+fait pas moitié*.
+
+La prop est désormais extraite dans `interfaces/Commons/attach.interface.ts` (`IAttachProps`) au
+lieu d'être redéclarée sur chaque interface, et consommée par le point unique existant,
+`useTeleport`.
+
+**Vérifié sur le parent DOM réel** du nœud téléporté, pas sur l'acceptation de la prop : les 9
+tests `attach` sont **9/9 rouges sur le commit parent**, verts sur la branche.
+
+### Added — `--origam-color__text---tertiary`
+
+Troisième niveau de texte sémantique, déclaré dans `light.css` (`neutral-500`) et `dark.css`
+(`neutral-400`), leurs jumeaux SCSS, et l'union `TTokenName`.
+
+Il était **lu par 27 fichiers** de `packages/marketing` et déclaré **nulle part** : un canal de
+thème mort depuis toujours, qui rendait correctement par son seul repli. Les pages de référence,
+`HomeThemes`, `WhyOrigamThemeDemo`, les pages d'administration et `apple.theme.ts` le consommaient
+tous dans le vide.
+
+⚠️ **Aplatissement assumé** : en mode sombre, `tertiary` et `secondary` résolvent la même valeur
+(`neutral-400`). Il n'existe aucun échelon entre `neutral-400` et `neutral-500`, et `neutral-500`
+sur la surface sombre mesure **4,18:1** — sous le seuil AA de 4,5:1. Un niveau de hiérarchie perdu
+a été préféré à une violation de contraste.
+
+### Fixed — `useTeleport` ne réévaluait jamais sa cible après l'hydratation
+
+Le `computed` qui résout la cible de téléportation n'avait **aucune dépendance réactive** sur
+`document.querySelector`. Sous SSR — et sous Histoire, où chaque story est enveloppée dans un
+`<Suspense>` — la première évaluation pouvait tomber **avant** que l'arbre voisin soit commité dans
+le DOM, et rien ne la redéclenchait ensuite.
+
+Le symptôme n'était pas théorique : quatre tests e2e du site marketing échouaient sur
+« *sans erreur JS console* » et « *pas d'erreur d'hydratation* ».
+
+Le correctif réutilise `useHydration()`, qui porte déjà les deux gardes nécessaires — `IN_BROWSER`
+et `ssr` — au lieu d'un compteur de montage local qui les ignorait. Le défaut touchait **toute la
+famille Overlay**, pas seulement les trois composants de ce lot ; c'est `OrigamDrawer` qui l'a
+révélé.
+
+### Fixed — le thème `origam` sombre posait un `text---tertiary` qui échoue en AA
+
+`origamDarkTheme` fixait `tertiary` à `#737373`, soit **4,18:1** sur la surface sombre. Le défaut
+était invisible parce que le canal n'était alimenté par aucune feuille — mais ce bloc runtime
+**gagne la cascade** sur la feuille, donc déclarer le token sans corriger ce thème n'aurait rien
+réglé en mode sombre. Attrapé par `theme-sheet-parity.spec.ts`, rouge avant / vert après.
+
 ## [2.21.0] - 2026-10-01
 
 ### Changed — ⚠️ `OrigamBlockquote` : le `variant` est un preset de props, plus un bloc SCSS