chore(ui): temporary Android WebView boot diagnostic (test contour only) #176

Merged
developer merged 7 commits from feature/webview-boot-diagnostic into development 2026-07-04 20:36:05 +00:00
2 changed files with 8 additions and 2 deletions
Showing only changes of commit 6dfd5203d7 - Show all commits
+1 -1
View File
@@ -162,7 +162,7 @@
['numeric separator 1_000', 'return 1_000', 75],
['dynamic import()', 'return import("")', 63],
];
var synPre = section('JS SYNTAX (esbuild target is es2022 — the bundle uses these)');
var synPre = section('JS SYNTAX (engine feature ceiling — first NO dates the engine)');
function mark(ok) {
return ok ? 'OK ' : 'NO ';
}
+7 -1
View File
@@ -54,7 +54,13 @@ export default defineConfig(({ mode }) => ({
},
},
build: {
target: 'es2022',
// Down-level to es2019 so an old Android System WebView (seen: Telegram/VK in-app WebView on
// Chromium 66, Android 9) can parse the bundle — esbuild lowers es2020+ syntax (?., ??, private
// fields, static blocks, …) that Chrome 66 rejects with "Unexpected token ?", which left the SPA
// on a white screen. esbuild lowers syntax only, not runtime APIs; the app's own source uses
// none beyond this floor (the mock-only helpers are tree-shaken from production). Reach for
// @vitejs/plugin-legacy if runtime-API polyfills for even older engines turn out to be needed.
target: 'es2019',
// Emit sourcemaps everywhere except the production build. A shipped `.map`
// carries full `sourcesContent` — the entire TypeScript/Svelte source — and the
// gateway/landing images serve `dist/` verbatim, so production maps would expose