tobias
4a58021670
Drei zusammenhaengende Runden, alle live bei 375x812 gegen audi_ha_test geprueft und in beiden Codebasen angewandt. Paritaetsrunde 2: der gemeinsame Rahmen war das eigentliche Problem - Seitenrand, Kachelabstaende, Kopfleiste, Tableiste und vier Bausteine des Design-Systems trugen noch den Stand vor der iOS-Entscheidung. Dazu sieben Bildschirme neu aufgebaut. Zwei Panel-Fehler dabei mitbehoben: teaser() zeigte unter "Letzte Fahrt" den aeltesten Datensatz, und "Daten bearbeiten" war ein toter Knopf. Paritaetsrunde 3: das Panel hat nie Audi Type gerendert. @font-face in einem Shadow Root wird ignoriert - Schriftschnitte registriert der Browser pro Dokument, nie pro Shadow Tree. Die drei Schnitte liegen jetzt in audi-dashboard-schriften.css und werden ins Dokument gehaengt. Damit erledigt sich eine ganze Reihe von "die Schrift sieht anders aus"-Eindruecken: die beiden Anwendungen zeigten tatsaechlich verschiedene Schriften. Ausserdem "Daten bearbeiten" im Panel gebaut und portiert, das Zeilenmenue entfernt und die letzten neun Bildschirme angeglichen. Designpruefung: die fuenf Punkte der Reihenfolge. Beim vierten hat das Messen den Befund veraendert - gezaehlt waren die deklarierten Groessen, wirksam war laengst eine saubere Sieben-Schritt-Skala mit 27 Ausreissern; die sind jetzt auf den naechsten Schritt gezogen, keiner verschiebt sich um mehr als 1px. Zuletzt: die Standortvorschau zeichnete die falsche Nadel (das Panel wechselt den Icon-Satz ab 34px, die App nahm immer den grossen), und der Kopfabstand der App ist auf den sicheren Bereich reduziert - die 56px des Panels liegen dort unter der Kopfleiste von Home Assistant, in der nativen Huelle steht darueber nichts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
67 lines
3.2 KiB
TypeScript
67 lines
3.2 KiB
TypeScript
import { readFileSync } from "node:fs"
|
|
import { fileURLToPath } from "node:url"
|
|
|
|
import { defineConfig } from "vite"
|
|
import react from "@vitejs/plugin-react"
|
|
|
|
// Die App-Version kommt aus der manifest.json der Integration — derselben
|
|
// Zahl, die Home Assistant als Version der Integration führt und die das
|
|
// Backend über sensor.audi_dashboard_app_version meldet (siehe
|
|
// VERSIONIERUNG.md). Sie wird hier fest einkompiliert, damit die fertige App
|
|
// weiß, aus welchem Stand sie gebaut wurde, und das gegen den vom Backend
|
|
// gemeldeten Stand halten kann.
|
|
//
|
|
// Bis 2026-08-23 stand die Zahl in einer eigenen Datei VERSION im
|
|
// Projektstamm. Die ist mit dem Umbau zur Integration überflüssig geworden:
|
|
// Home Assistant selbst verlangt ein version-Feld in jeder manifest.json,
|
|
// unabhängig von HACS (das für dieses private Repository ohnehin dauerhaft
|
|
// ausscheidet, siehe AGENTS.md Abschnitt H). Zwei Quellen für dieselbe
|
|
// Angabe wären eine Quelle zu viel — sie hätten irgendwann
|
|
// auseinandergelegen, und der Vergleich, den diese Zahl trägt, wäre still
|
|
// falsch geworden.
|
|
//
|
|
// Absichtlich hart: fehlt die Datei oder das Feld, soll der Build abbrechen
|
|
// statt still eine App ohne Versionsangabe zu erzeugen — die könnte ihre
|
|
// eigene Veraltung nicht mehr erkennen, und genau das ist der Zweck der
|
|
// ganzen Mechanik.
|
|
const manifestPfad = fileURLToPath(
|
|
new URL("../custom_components/audi_dashboard/manifest.json", import.meta.url),
|
|
)
|
|
const appVersion: string = JSON.parse(readFileSync(manifestPfad, "utf8")).version
|
|
if (!appVersion) throw new Error(`Kein "version"-Feld in ${manifestPfad}`)
|
|
|
|
// Basispfad relativ: die App wird sowohl unter einer eigenen Domain als auch
|
|
// aus einem Unterordner heraus ausgeliefert (Home Assistant: /local/dm360/),
|
|
// und in der Capacitor-Hülle direkt vom Dateisystem.
|
|
export default defineConfig({
|
|
base: "./",
|
|
plugins: [react()],
|
|
define: { __APP_VERSION__: JSON.stringify(appVersion) },
|
|
// Nur fuer `vite dev` (server.* wirkt nie in `vite build`, also risikolos
|
|
// fuer die echte App). Der Browser darf `/api/...` gegen den eigenen
|
|
// Vite-Ursprung aufrufen - das ist same-origin, keine Praeflight-Anfrage
|
|
// noetig - und Vite selbst (ein Node-Prozess, keine Browser-CORS-Regeln)
|
|
// reicht das serverseitig an die HA-Testinstanz weiter. Sonst blockt HA
|
|
// die Anfrage direkt (siehe AGENTS.md: "CORS ist ein echter Zwang fuer
|
|
// diese App" - `cors_allowed_origins` wirkt seit HA 2026.8 nicht). Nur
|
|
// gegen `audi_ha_test` (:18123) - die echte Instanz wird nie beruehrt.
|
|
server: {
|
|
port: 5173,
|
|
proxy: {
|
|
"/api": { target: "http://localhost:18123", changeOrigin: true, ws: true },
|
|
// Fahrzeugfotos (/local/bilder/...) und die Statikdateien der
|
|
// Integration (Markenlogo) liegen ebenfalls auf der HA-Instanz. Ohne
|
|
// diese beiden Eintraege liefert der Dev-Server sie selbst - also gar
|
|
// nicht - und jeder optische Abgleich gegen das Panel sieht nur
|
|
// Platzhalter statt der echten Bilder.
|
|
"/local": { target: "http://localhost:18123", changeOrigin: true },
|
|
"/audi_dashboard_static": { target: "http://localhost:18123", changeOrigin: true },
|
|
},
|
|
},
|
|
build: {
|
|
outDir: "dist",
|
|
target: "es2022",
|
|
sourcemap: true,
|
|
},
|
|
})
|