@nodefony/frontend 10.0.0-alpha.3 → 10.0.0-alpha.5

package/dist/types/nodefony/src/remoteDev.d.ts

@@ -5,7 +5,7 @@
  * NAVIGATEUR utilise peut être toute autre chose — un forwarder TLS (Codespaces,
  * Gitpod), une passerelle de conteneur (`host.docker.internal`), un port remappé.
  * Ce module dissocie les deux : il produit l'origine publique (assets, `base`
- * Vite, WebSocket HMR) à partir d'un TEMPLATE (`{port}` substitué au port réel
+ * Vite) à partir d'un TEMPLATE (`{port}` substitué au port réel
  * du spawn) — explicite (`frontend.publicOrigin`) ou détecté depuis
  * l'environnement de la plateforme.
  *
@@ -14,7 +14,7 @@
  *
  * Formats VÉRIFIÉS (docs officielles + source Vite 8) :
  *  - Codespaces : `https://${CODESPACE_NAME}-${port}.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}`
- *    (TLS terminé par le forwarder → WS HMR en `wss` sur 443).
+ *    (TLS terminé par le forwarder ; le socket HMR s'en déduit côté client).
  *  - Gitpod classic : `https://${port}-<hôte de GITPOD_WORKSPACE_URL>`.
  *  - Vite `server.allowedHosts` : IP et `localhost`/`*.localhost` TOUJOURS
  *    acceptés ; un préfixe `.` = le domaine ET tous ses sous-domaines.
@@ -27,15 +27,6 @@ export declare const PORT_PLACEHOLDER = "{port}";
 export interface IResolvedPublicOrigin {
     /** Origine que le navigateur utilise — verbatim dans les `<script>` et le `base` Vite. */
     readonly origin: string;
-    /**
-     * Config `server.hmr` cliente : le WS HMR doit suivre le MÊME chemin que les
-     * assets. Port implicite → 443/80 selon le scheme (cas forwarder TLS).
-     */
-    readonly hmr: {
-        readonly host: string;
-        readonly clientPort: number;
-        readonly protocol: "ws" | "wss";
-    };
 }
 /** Environnement de dev déporté détecté depuis les variables de la plateforme. */
 export interface IRemoteDevDetection {
@@ -51,6 +42,31 @@ export interface IRemoteDevDetection {
  * sous Windows, une CONNEXION vers `0.0.0.0` échoue aussi (health check).
  */
 export declare function browserReachableHost(listenHost: string): string;
+/**
+ * Le client est-il arrivé par la BOUCLE LOCALE de la machine qui sert ?
+ *
+ * Ce n'est pas une commodité : c'est un fait vérifiable qui prime sur toute
+ * déduction faite au démarrage. Une plateforme de dev déporté se détecte par
+ * une variable d'environnement — donc UNE FOIS, au lancement du serveur — alors
+ * qu'un même serveur reçoit simultanément des clients arrivés par des chemins
+ * différents : l'origine publique de la plateforme, et un tunnel local (VS Code
+ * Desktop redirige les ports d'un Codespace sur `localhost`, c'est sa
+ * configuration par défaut).
+ *
+ * Servir l'origine publique à un client venu du tunnel a un coût réel : cette
+ * origine exige la session de la plateforme. Un navigateur humain la porte et
+ * ne voit rien ; une intégration continue, une sonde ou un agent ne l'ont pas,
+ * se font refuser, et obtiennent une page blanche que rien n'explique.
+ *
+ * La liste est FERMÉE, et c'est ce qui la rend sûre : le `Host` est une donnée
+ * cliente, et seuls ces noms désignent la machine locale de façon non
+ * ambiguë. `0.0.0.0`/`::` en sont exclus — ce sont des adresses d'écoute, pas
+ * des destinations (cf `browserReachableHost`).
+ *
+ * @param hostname - nom d'hôte NU, sans port (`[::1]` pour l'IPv6 canonique).
+ * @returns `true` si ce nom désigne la boucle locale.
+ */
+export declare function isLoopbackHostname(hostname: string): boolean;
 /** Un template d'origine est-il syntaxiquement valide ? (autorité unique) */
 export declare function isValidOriginTemplate(template: string): boolean;
 /**
@@ -76,9 +92,10 @@ export declare function originWithHostname(origin: string, hostname: string): st
 /**
  * Résout un template d'origine contre le port RÉEL du spawn. Pure.
  *
- * @returns origine + config HMR cliente, ou `null` si le template est invalide
+ * @returns l'origine publique, ou `null` si le template est invalide
  *   (l'appelant retombe sur la dérivation locale en l'ANNONÇANT — jamais en
- *   silence).
+ *   silence). Aucune config HMR n'est rendue : le socket suit l'origine par
+ *   laquelle le client Vite a été chargé, il n'a rien à recevoir.
  */
 export declare function resolveOriginTemplate(template: string, port: number): IResolvedPublicOrigin | null;
 /**

package/docs/index.md

@@ -370,7 +370,7 @@ JSON Schema pour l'écran de configuration de Studio.
 > **`backendPort` n'est pas forcément le port écouté.** Avec une politique de port automatique, un
 > 5151 occupé fait glisser l'écoute sur 5153. Un proxy figé enverrait alors les appels de ton
 > interface vers le serveur d'une **autre** application. Le module lit donc le port réel sur le
-> serveur lui-même (`FrontendService.resolveBackendPort()`, `FrontendService.ts:455`) et journalise
+> serveur lui-même (`FrontendService.resolveBackendPort()`, `FrontendService.ts:471`) et journalise
 > l'écart.
 
 ### Le build de production
@@ -490,8 +490,8 @@ intermittent, apparaissant seulement quand le navigateur est plus rapide que le
 | ----------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------- |
 | `FrontendService`       | l'orchestrateur : entrées, familles, cycle de vie, rendu           | `FrontendService.ts:70`                                     |
 | `ViteProcessSupervisor` | lance, surveille, relance et arrête **un** processus Vite          | `ViteProcessSupervisor.ts:215`                              |
-| `ViteConfigGenerator`   | écrit la configuration Vite (fonction pure, testée seule)          | `ViteConfigGenerator.toMjs()` (`ViteConfigGenerator.ts:80`) |
-| `ViteBuilder`           | construit l'objet de configuration Vite pour le build en processus | `ViteBuilder.buildViteConfig()` (`ViteBuilder.ts:41`)       |
+| `ViteConfigGenerator`   | écrit la configuration Vite (fonction pure, testée seule)          | `ViteConfigGenerator.toMjs()` (`ViteConfigGenerator.ts:69`) |
+| `ViteBuilder`           | construit l'objet de configuration Vite pour le build en processus | `ViteBuilder.buildViteConfig()` (`ViteBuilder.ts:95`)       |
 | `TemplateHelper`        | produit les balises (dev) ou lit le manifeste (prod)               | `TemplateHelper.ts:36`                                      |
 | `isolationGroups`       | à quelle famille appartient un preset, et sur quel bloc de ports   | `isolationGroup()` (`isolationGroups.ts:39`)                |
 | `FrontendAdminApi`      | la vue sûre de l'état, pour Studio                                 | `buildFrontendStatus()` (`FrontendAdminApi.ts:139`)         |
@@ -597,7 +597,7 @@ et dans les types du paquet — jamais recopiées ici, où elles se périmeraien
 
 ### `registerEntry` — la déclaration d'une interface
 
-`FrontendService.registerEntry()` (`FrontendService.ts:221`) est appelée par le module consommateur,
+`FrontendService.registerEntry()` (`FrontendService.ts:243`) est appelée par le module consommateur,
 dans son `onKernelBoot()`. Elle résout les chemins relatifs, calcule le préfixe public et renvoie
 l'entrée résolue (`IResolvedFrontendEntry`, `IFrontBuilder.ts:40`).
 
@@ -637,7 +637,7 @@ const tags = frontend.renderTags("shop", context.cspNonce);
 const html = frontend.renderDocument("shop", context.cspNonce);
 ```
 
-`renderDocument` (`FrontendService.ts:876`) lit l'`index.html` **de ton module**, retire le `<script>`
+`renderDocument` (`FrontendService.ts:904`) lit l'`index.html` **de ton module**, retire le `<script>`
 d'entrée source, injecte les balises au marqueur (ou avant `</head>`), et renvoie le document.
 Pas d'`index.html` ? Une coquille minimale est générée. En production, l'index est mis en cache ; en
 développement il est relu à chaque appel, pour que tes modifications de la coquille apparaissent.
@@ -650,7 +650,7 @@ Ce qui est injecté en développement (`TemplateHelper.renderDevTags()`, `Templa
 3. ton entrée, servie par son **chemin absolu** (`/@fs/…`) plutôt que relatif — c'est ce qui permet à
    deux modules d'avoir chacun leur `frontend/src/main.tsx` sans collision ;
 4. un pont qui relaie les événements de rechargement vers la barre de débogage, **sans ouvrir de
-   seconde connexion** (`hmrBridgeTag()`, `TemplateHelper.ts:226`) ;
+   seconde connexion** (`hmrBridgeTag()`, `TemplateHelper.ts:267`) ;
 5. la barre de débogage elle-même, résolue une fois et servie via Vite (`debugBarTag()`,
    `TemplateHelper.ts:252`).
 
@@ -660,7 +660,7 @@ l'état. Une page dégradée reste une page.
 ### Les helpers de vue
 
 Si tu rends une vue Eta plutôt qu'une chaîne, trois helpers sont déjà dans tes variables locales
-(`Controller.withFrontendLocals()`, `Controller.ts:345`) — inspirés des helpers d'assets de Symfony :
+(`Controller.withFrontendLocals()`, `Controller.ts:448`) — inspirés des helpers d'assets de Symfony :
 
 ```html
 <%~ frontendDocument("shop") %>
@@ -699,7 +699,7 @@ Quatre comportements à connaître :
   les autres résultats.
 - **Le résultat est un bilan** : construits / ignorés / en échec, journalisé et renvoyé.
 - **Un démarrage en production sans build se répare — ou se dénonce.** `setupProd()`
-  (`FrontendService.ts:655`) vérifie le manifeste de chaque entrée AVANT de monter les statics.
+  (`FrontendService.ts:683`) vérifie le manifeste de chaque entrée AVANT de monter les statics.
   Manifeste absent et Vite installé (poste de développement, devDependencies présentes) : le build
   tourne **une fois au démarrage**, annoncé en WARNING — fini l'écran blanc après un
   `nodefony production --detach` lancé trop tôt. Manifeste absent et Vite introuvable (image de
@@ -735,7 +735,7 @@ use("@nodefony/frontend", { assetBaseUrl: "https://cdn.example.com" });
 // → <script src="https://cdn.example.com/_assets/shop/main-a1b2c3.js">
 ```
 
-En production, `setupProd()` (`FrontendService.ts:655`) monte chaque dossier de sortie sur son
+En production, `setupProd()` (`FrontendService.ts:683`) monte chaque dossier de sortie sur son
 `publicPath` via le serveur statique — résolu **par nom**, jamais par import, pour ne pas créer de
 cycle. Si ce service est absent (proxy frontal, CDN devant), un avertissement le dit et rien n'est
 monté : c'est un déploiement valide, pas une panne.
@@ -765,7 +765,7 @@ Deux points d'attention avant de se lancer :
 
 - le preset alimente le build en processus (`ViteBuilder`), mais la configuration du **serveur de
   développement** est écrite par le générateur, qui possède sa propre correspondance type → greffon
-  (`ViteConfigGenerator.toMjs()`, `ViteConfigGenerator.ts:80`). Un nouveau type doit être ajouté aux
+  (`ViteConfigGenerator.toMjs()`, `ViteConfigGenerator.ts:69`). Un nouveau type doit être ajouté aux
   **deux** endroits, sinon il lève `FrontendPresetUnknownError` (`FrontendError.ts:19`) ;
 - si le nouveau framework transforme des fichiers qui ne lui appartiennent pas, il lui faut sa propre
   famille d'isolation — c'est la leçon d'Angular.
@@ -782,10 +782,10 @@ origine. Or en développement, tes modules viennent du port 5173 alors que ta pa
 
 La solution retenue n'est pas d'affaiblir la politique, mais de la **composer**. Une fois Vite prêt
 (donc ses ports réellement connus), le service déclare ses origines au pare-feu
-(`#registerCsp()`, `FrontendService.ts:948`), qui émet **un seul** en-tête, origines fusionnées et
+(`#registerCsp()`, `FrontendService.ts:990`), qui émet **un seul** en-tête, origines fusionnées et
 nonce par requête. À l'arrêt, les origines sont retirées et la politique redevient stricte.
 
-Le fragment déclaré (`#viteCspFragment()`, `FrontendService.ts:909`) mérite deux explications, parce
+Le fragment déclaré (`#viteCspFragment()`, `FrontendService.ts:1012`) mérite deux explications, parce
 qu'elles piègent tout le monde :
 
 - **`'self'` est répété dans chaque directive.** `connect-src`, `style-src`, `img-src` et `font-src`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nodefony/frontend",
-  "version": "10.0.0-alpha.3",
+  "version": "10.0.0-alpha.5",
   "description": "Construction et rechargement à chaud des frontends de chaque module Nodefony — Vite intégré, multi-framework (React, Vue, Angular, Svelte)",
   "author": "Christophe CAMENSULI <ccamensuli@gmail.com>",
   "type": "module",
@@ -36,28 +36,28 @@
     "esm"
   ],
   "peerDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.3",
-    "@nodefony/http": "^10.0.0-alpha.3",
-    "nodefony": "^10.0.0-alpha.3",
-    "zod": "^4.4.3"
+    "@nodefony/framework": "^10.0.0-alpha.5",
+    "@nodefony/http": "^10.0.0-alpha.5",
+    "nodefony": "^10.0.0-alpha.5",
+    "zod": "^4.6.1"
   },
   "devDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.3",
-    "@nodefony/http": "^10.0.0-alpha.3",
+    "@nodefony/framework": "^10.0.0-alpha.5",
+    "@nodefony/http": "^10.0.0-alpha.5",
     "@types/chai": "5.2.3",
-    "@types/node": "26.4.1",
+    "@types/node": "26.5.1",
     "@vitest/coverage-v8": "5.0.0",
     "chai": "6.2.2",
-    "nodefony": "^10.0.0-alpha.3",
+    "nodefony": "^10.0.0-alpha.5",
     "rimraf": "6.1.3",
-    "vite": "8.2.2",
+    "vite": "8.3.0",
     "vitest": "5.0.0"
   },
   "private": false,
   "engines": {
     "node": ">=24.0.0"
   },
-  "license": "CECILL-B",
+  "license": "Apache-2.0",
   "dependencies": {
     "tslib": "2.8.1"
   },