Open zmb3 opened 1 year ago
What do you mean by archiving? Do you mean just including source maps with the Web UI in the teleport binary?
The following diff seems to do the job. But I haven't checked by how much it increases the build time. I know in Webpack generating full-fledged sourcemaps was a costly task, but I think Vite might be much faster with that.
diff --git a/web/packages/build/vite/config.ts b/web/packages/build/vite/config.ts
index 79733501c4..f7305efe7a 100644
--- a/web/packages/build/vite/config.ts
+++ b/web/packages/build/vite/config.ts
@@ -62,6 +62,7 @@ export function createViteConfig(
outDir: outputDirectory,
assetsDir: 'app',
emptyOutDir: true,
+ sourcemap: true,
},
plugins: [
react({
On my device, this adds ~1.5s to make build-ui
, which I feel warrants running it on CI only.
By archive I was thinking we just upload them to S3 or something. I don't want to bloat the binary any further.
Oh, that's interesting, I've never actually worked with "out of band" source maps like this. I assume the process of untangling stack traces would be manual but for HAR files we'd be able to use some browser tooling, right?
I haven't either 😅 but that's what I'm hoping.
Having source maps of the web UI for each release that we can refer back to when troubleshooting will help resolve issues faster.
Without source maps, stack traces in error messages and HAR files refer to arbitrary line numbers in compiled/minified JS. Mapping these back to the original source would provide equivalent troubleshooting to what we have in our Go logs.