fix: remove broken source map infrastructure (sourcemapPlugin, stacktrace-js, sourceMapInitializer)

[edelauna]

Context

The source map infrastructure added in #5085 is broken by design in the VSCode webview environment and adds unnecessary overhead to CI test runs. This issue documents the problems and recommends a path forward grounded in official VSCode documentation and tracked GitHub issues.

---

Problems

1. External .map files don't load in webview DevTools (known VSCode bug)

vite.config.ts uses sourcemap: true, which generates external .map files. This is a known, documented VSCode issue (#145292, #115440, #133867) — DevTools tries to fetch .map files over the vscode-resource:// scheme but fails with net::ERR_NAME_NOT_RESOLVED or 503 errors. The files exist but can't be resolved from the webview context.

The sourcemapPlugin reads, parses, and pretty-prints all 359 JS chunks and their .map files post-build to ensure correct //# sourceMappingURL= references and relative source paths — but the processed .map files still can't be loaded by DevTools. The plugin is fixing files that are broken by design.

Additionally, the plugin runs as part of the pretest → turbo run bundle → webview build pipeline, generating 710 log lines and performing ~720 synchronous file reads/writes on every CI test run.

The official workaround per the VSCode issues above: use sourcemap: 'inline' instead of sourcemap: true. Inline source maps are embedded as base64 data URIs in each JS file — no network request, no CSP issue, no wrong context.

2. stacktrace-js runtime source map resolution is blocked by CSP

sourceMapUtils.ts uses stacktrace-js to resolve source maps by fetching .map files via fetch() at runtime. VSCode's webview CSP restricts outbound fetch requests, and the .map files can't be fetched from the webview context (per finding #1). The library silently falls back to the original unresolved stack every time.

This is confirmed by the tests themselves — sourceMapUtils.spec.ts contains the comment:

"For now, we expect it to return the original stack since we haven't implemented actual source map application"

The tests pass because the function gracefully no-ops, not because it works. The stacktrace-js and source-map packages ship in the production webview bundle for zero benefit.

3. sourceMapInitializer.ts makes wasteful requests on every startup

Called from App.tsx on every load, this initializer:

• Creates 5 preload link hints per <script> tag for non-standard URLs (.map.json, .sourcemap, ?source-map=true, etc.) — all 404 silently
• fetch(script.src)-es every script's full content just to regex for a //# sourceMappingURL= comment the browser engine already parsed
• All of this likely blocked by CSP in the webview context anyway

This is a browser web-app pattern that doesn't apply to VSCode webviews.

4. source-map npm package is unused

Listed as a production dependency in webview-ui/package.json but never imported anywhere in the codebase. It gets bundled into the webview for no reason.

---

Recommended Fix

Item	Action
webview-ui/src/vite-plugins/sourcemapPlugin.ts	Delete
vite.config.ts sourcemap: true	Change to sourcemap: 'inline' (or false for production if bundle size is a concern)
webview-ui/src/utils/sourceMapInitializer.ts	Delete
webview-ui/src/utils/sourceMapUtils.ts	Delete
stacktrace-js + @types/stacktrace-js deps	Remove
source-map dep	Remove
ErrorBoundary.tsx	Simplify — keep the error boundary, remove enhanceErrorWithSourceMaps call, log raw stack
webview-ui/src/utils/__tests__/sourceMapUtils.spec.ts	Delete (tests for deleted module)

Correct approach for production error reporting

The right pattern per VSCode's telemetry guide:

1. ErrorBoundary catches the error in the webview
2. Sends raw error + stack via postMessage to the extension host
3. Extension host (Node.js, no CSP restrictions) handles logging/telemetry via @vscode/extension-telemetry

The webview is the wrong place to resolve source maps at runtime. The extension host is the right place.

---

References

• Webview API — VSCode Extension Docs
• DevTools failed to load source map · Issue #145292 · microsoft/vscode
• Webview dev tools can no longer load source maps · Issue #115440 · microsoft/vscode
• VSCode extension launch and debug with external source maps · Issue #133867 · microsoft/vscode
• Vite Build Options — sourcemap
• Telemetry extension authors guide — VSCode Extension Docs