Blomios
481a7e2498
Enregistre l'état du registre de tickets : #74 et #68 passent en closed après la validation live de l'intégration web, #75 (ce fix) entre en QA et #76 ouvre la dette de casse du code d'appairage côté serveur. État runtime uniquement : aucun code de feature n'est touché. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
67 lines
3.4 KiB
Markdown
67 lines
3.4 KiB
Markdown
---
|
|
id: "249bb0de-118f-4d6f-b0c4-1d4e2aadd83f"
|
|
number: 74
|
|
title: "Le serveur embarqué sert le bundle desktop (Tauri) au navigateur — __TAURI_INTERNALS__ undefined"
|
|
status: "closed"
|
|
priority: "high"
|
|
sprint: null
|
|
links: [{"target":"#68","kind":"relatesTo"},{"target":"#66","kind":"relatesTo"},{"target":"#13","kind":"relatesTo"}]
|
|
agentRefs: []
|
|
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
|
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
|
createdAt: 1784271086298
|
|
updatedAt: 1784277308704
|
|
version: 3
|
|
---
|
|
## Symptôme (constaté live, exposition derrière reverse proxy)
|
|
|
|
UI chargée dans le navigateur via `https://idea.anthonybouteiller.ovh` (nginx → 192.168.1.75:17373, serveur embarqué desktop, mode `remoteProxyOtherMachine`) :
|
|
|
|
- `Error: can't access property "invoke", window.__TAURI_INTERNALS__ is undefined` (x2)
|
|
- Aucun projet affiché.
|
|
|
|
## Cause racine (confirmée)
|
|
|
|
`crates/app-tauri/tauri.conf.json` utilise **un seul** `frontend/dist` pour deux besoins incompatibles :
|
|
|
|
- `build.frontendDist: "../../frontend/dist"` + `beforeBuildCommand: "npm --prefix ../frontend run build"` → `vite build` **sans** `VITE_TRANSPORT` → bundle **desktop** (transport `tauri`).
|
|
- `bundle.resources: { "../../frontend/dist": "web" }` → ce **même** bundle desktop est packagé en ressource `web/`.
|
|
|
|
Or `resolve_web_root()` (`crates/app-tauri/src/embedded_server.rs:498-517`) sert `resource_dir.join("web")`. Le serveur embarqué sert donc le bundle desktop au navigateur.
|
|
|
|
Le transport est figé **au build** par Vite : `resolveTransport()` (`frontend/src/app/di.tsx:39-46`) lit `import.meta.env.VITE_TRANSPORT`, constant-folded à la compilation.
|
|
|
|
**Preuve** dans `frontend/dist/assets/index-nl-2Eu6U.js` (build du 2026-07-17 08:00) :
|
|
|
|
```js
|
|
function Cb(){return"tauri"} // resolveTransport() figé sur tauri
|
|
```
|
|
|
|
Les deux jeux d'adapters sont bien présents dans le bundle, mais le sélecteur ne pointera jamais sur `createHttpWsGateways()`.
|
|
|
|
## Attendu
|
|
|
|
L'AppImage doit packager en ressource `web/` un bundle construit avec `VITE_TRANSPORT=http`, distinct du `frontendDist` desktop. Un seul `dist` ne peut pas servir les deux transports.
|
|
|
|
## Contexte
|
|
|
|
- `docs/server-client-mode-remote.md` documente déjà que le build web **doit** être produit en `VITE_TRANSPORT=http`, sinon exactement ce symptôme.
|
|
- Le carnet de #13 avait classé ce symptôme en « erreur de commande de test, pas un bug de code » — vrai à l'époque de `idea --serve --web-root`, mais le packaging AppImage de #66/#68 réintroduit le problème par défaut.
|
|
- #66 L4 anticipait le besoin (« produire les assets client Vite en `VITE_TRANSPORT=http` … packager dans `/usr/share/idea/web` ») ; la conf actuelle ne le fait pas.
|
|
- npm, jamais pnpm (mémoire `frontend-uses-npm-not-pnpm`).
|
|
|
|
## Workaround live
|
|
|
|
Build séparé + `IDEA_WEB_ROOT` (premier candidat de `resolve_web_root`, court-circuite la ressource packagée) :
|
|
|
|
```bash
|
|
cd frontend && VITE_TRANSPORT=http npx vite build --outDir dist-web --emptyOutDir
|
|
IDEA_WEB_ROOT=…/frontend/dist-web ./IdeA.AppImage
|
|
```
|
|
|
|
## DoD
|
|
|
|
- Build AppImage produit une ressource `web/` en transport http, `frontendDist` desktop inchangé.
|
|
- Vérif automatisable : le bundle servi ne doit pas résoudre le transport sur `tauri`.
|
|
- Validation live navigateur derrière reverse proxy : UI + projets listés, aucune erreur `__TAURI_INTERNALS__`.
|
|
- Rebuild AppImage livrable pour test utilisateur. |