I’m working with Puppeteer to test a web application that was bundled using webpack. When I listen for errors using page.on('error'), the stack traces I receive are pointing to the minified bundle instead of the original source files.
Here’s an example of what I’m getting:
ReferenceError: myLibrary_Promise_default.a.forEach is not a function
at CustomClass.<anonymous> (bundle.js:12456:78)
at Generator.next (<anonymous>)
at processNext (bundle.js:18923:45)
at bundle.js:18934:22
My webpack build definitely creates source maps (I can confirm they exist), but Puppeteer doesn’t seem to be using them when reporting errors. Is there a configuration option or method to make Puppeteer resolve these error locations back to the original source files? I need to see the actual file names and line numbers from my source code rather than the compiled bundle positions.
you can also set devtool to ‘inline-source-map’ in your webpack config instead of external maps. this embeds the sourcemap data right into the bundle, so puppeteer can access it without needing separate .map files. makes the file bigger but you don’t have to serve the maps or deal with source-map-support libs.
I had the same issue and fixed it by enabling source map support directly in the browser before hitting the page. Just inject the source-map-support module using page.evaluateOnNewDocument() - it patches Error.prepareStackTrace automatically to resolve source maps on the fly. Install source-map-support via npm, then add await page.evaluateOnNewDocument(() => { require('source-map-support').install(); }); before navigating. You’ll need your source maps accessible from the browser context though, so serve them with your bundle files. This worked great for my React apps where I didn’t want separate build configs. Stack traces became way more readable and pointed straight to my TypeScript files instead of webpack output.
Puppeteer does not automatically resolve source maps during error handling; you need to implement this yourself. I faced a similar issue while debugging an Angular application. To resolve it, I used the ‘source-map’ npm package. The approach is to catch the error event and extract the line and column numbers from the stack trace. Then, the SourceMapConsumer can be utilized to map these back to your original code. Ensure that you load the corresponding .map files and set up consumers for each bundle. While this solution works, a simpler approach could be to run your tests against unminified builds during development. We maintain two separate webpack configurations: one for production, which includes minification, and another for testing that omits it. This eliminates the headache of dealing with source maps and significantly simplifies debugging.