Production JavaScript errors reach your tracker with stacks like `at n (app.9f3.js:1:24817)`. Explain what produced that and how you recover the original function, file and line.

## Why the frames look like that A stack trace names positions in the code the engine loaded. In production that code has been through a minifier: local and often top-level function names are replaced with one- or two-character identifiers, whitespace is removed, and modules are concatenated so the whole bundle may be one enormous line. `at n (app.9f3.js:1:24817)` is not corrupted — it is a precise reference to column 24817 of line 1 of a file whose symbols no longer mean anything to a human. Nothing in the language is misbehaving here. `stack` is captured from real positions in real loaded code, and that code is the transformed artifact. ## What a source map is Alongside the bundle, the build emits a source map: a JSON document whose main fields are `version`, `sources` (the original file paths), `sourcesContent` (optionally the original text inline), `names` (the original identifiers), and `mappings` — a compact, base64-VLQ-encoded table that relates generated line/column positions to original file, line, column, and where possible original name. The bundle usually ends with a directive naming it: ```js //# sourceMappingURL=app.9f3.js.map ``` Given a generated position, a consumer of the map can look up the original position and name. That is the whole recovery mechanism: it is a lookup table, applied *after* a trace exists. ## The point people get wrong Browsers do not apply source maps to the `error.stack` string. Devtools fetch the map and remap what it *displays* — so a developer with the console open sees pleasant original names — but the string an in-page error reporter reads and POSTs to your backend still contains `n` and `1:24817`. This is why a team can "have source maps working" and still receive unreadable production traces: two different consumers, only one of which is remapping. So symbolication has to happen somewhere the map is available: - **Client-side errors:** upload the map for that build to the error tracker as part of deployment, and let it remap on ingestion, keyed by the bundle's filename or an explicit release identifier. This is the normal arrangement, and it keeps the map off the public web. - **Server-side (Node):** Node can apply maps to `error.stack` itself when the process is started with `--enable-source-maps`, which is the documented opt-in; equivalent programmatic switches exist in recent versions. Check what your Node major does by default rather than assuming. - **Custom:** a library can install V8's `Error.prepareStackTrace` hook to rewrite frames as they are formatted. It works, but it is engine-specific global state and a poor thing for a dependency to seize. ## The map must match the build exactly Mappings are positional. A map from a rebuild — even one with an identical source tree, if the minifier's output shifted by a byte — resolves frames to the wrong original lines, which is worse than no map at all because the result looks plausible. Practical consequences: - Tie maps to an immutable build identity: content-hashed filenames, or an explicit release version that the client reports with every error. - Upload maps as part of the same deploy step that publishes the bundle, never as a separate later job. - Keep old maps as long as old clients might still be running; a browser tab open across two deploys will report against the previous bundle. ## Serving maps publicly If the `.map` file is reachable from the public origin, anyone can fetch it and — with `sourcesContent` included — reconstruct your original source, comments and all. Whether that matters is a judgment call, but it should be a decision rather than an accident. The common posture is to publish the bundle without a publicly reachable map and to give the map only to the error tracker. Note that removing the `//# sourceMappingURL` comment alone is not a control: it stops automatic discovery, not a request to a guessable URL. ## The other trace killers to check first Before blaming the map, rule out the cheaper explanations, because they look similar in a tracker: - **Truncation.** V8 captures at most `Error.stackTraceLimit` frames, default 10, and cuts silently. - **Async boundaries.** Frames from the code that scheduled the work were already unwound; no map recovers them. - **Lost chaining.** Someone caught a low-level failure and threw a fresh error without attaching a `cause`, so the deep frames were never linked in the first place. A symbolicated trace of the wrong ten frames is still a bad trace. Source maps solve the readability problem; they do not solve the completeness problem, and a strong answer says so.