---
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.