Debugging Online JavaScript Errors with Source Maps and Charles Proxy

When a production JavaScript error occurs, the minified code makes it hard to locate the source. This article shows how to use VSCode exception breakpoints together with source maps to debug the original source.

First, create a simple JS file that throws an error, bundle it with webpack, and serve it via a static server. The error appears in the browser but the stack trace points to minified variables.

Configure webpack’s devtool to hidden-source-map (or source-map) to generate a .map file without exposing it publicly. The map can be linked by adding //# sourceMappingURL=xxx.js.map at the end of the compiled file.

Since the production file cannot be edited directly, use Charles Proxy to intercept the request for the compiled script, add the source‑mapping comment, and forward the modified response. Set up a local host entry (e.g., www.guangtest.com → 127.0.0.1) and configure SwitchyOmega to route that domain through Charles.

In Charles, enable “Breakpoint Settings” for the script URL, modify the response to include the source‑mapping line, and execute the change. The browser now receives the script with the map reference.

Back in VSCode, add an “Uncaught Exception” breakpoint in the launch configuration. When the page reloads, the debugger stops at the original source line, allowing inspection of variables, call stack, and scopes just like in local development.

Thus, by generating a source map, injecting it via a proxy, and using exception breakpoints, you can debug production JavaScript errors as if you were debugging locally.