Qwik Optimizer + Node.js Adapter: Interaction of sourceMap Flag on Production Stack Trace Preservation

The short answer

No — setting sourceMap: true in the Qwik optimizer config is necessary but not sufficient. It only causes the build to emit .js.map files next to the optimized server bundle. Whether production logs show original file names and line numbers depends on two more things: the map files actually reaching the runtime environment, and Node.js being started with source-map translation enabled. Miss either one and your traces still point at generated, segmented output.

Why the flag alone doesn't do it

Qwik's optimizer rewrites your code heavily — the $ marker splits components into lazy-loaded segments with generated names. Without mapping, a stack frame like chunk-abc123.js:1:4821 is all you get. The sourceMap option makes the build emit .map files, but Node.js does not consult them by default. Node only rewrites stack traces through source maps when started with --enable-source-maps (available since Node 12.12). The Qwik Node.js adapter does not turn this on for you, so you must add it yourself:

NODE_OPTIONS=--enable-source-maps node server/entry.express.js

The three failure points to check, in order

1. Build output: run your production build and confirm .js.map files exist next to the server entry in the adapter's output directory (commonly dist/server or server/).
2. Deployment packaging: this is the most common culprit. A .dockerignore, a *.map exclusion in a copy step, or a Dockerfile that copies only *.js silently strips the maps. Verify the files exist inside the running container/host, not just locally.
3. Runtime flag: confirm --enable-source-maps is actually applied — e.g. node -e "console.log(process.execArgv)" in the same environment, or check NODE_OPTIONS survives your process manager.

Version differences (v1.x vs v2.x)

Optimizer option names and defaults have shifted across Qwik and @builder.io/qwik-city releases, so a config key that worked in one line may be ignored — silently — in another. Treat the exact flag name as version-specific: check the optimizer options exported by the version pinned in your package.json rather than copying a config from a blog post. If the build emits no .map files at all, a renamed or relocated option is the first thing to suspect. Behavior of --enable-source-maps also varies between Node majors, so pin and test on your production Node version.

Truncation and hydration-blind errors

The adapter writes errors to stderr via Node's normal console.error/uncaughtException path; it does not deliberately shorten traces, but very deep stacks can appear clipped by your log collector's line limits rather than by Qwik. Separately, errors thrown inside lazy-loaded components that only execute after client-side hydration never reach the server at all — no server config will log them. Those need client-side reporting (e.g. a window.onerror hook or an error-tracking SDK).

If you'd rather not map at runtime

Source maps add startup/memory overhead and expose original source. A common alternative: log the raw minified stack, ship or archive the .map files privately, and resolve traces offline with a source-map library — or upload maps to an error-tracking service and let it symbolicate. This keeps production output clean while preserving full diagnosability.

Verification checklist

• Build for production; confirm .js.map files beside the server entry.
• Start with --enable-source-maps, throw a test error in a route, and check the trace shows your original .tsx file and line.
• If still minified, exec into the deployed environment and confirm the maps are present there.