Sentry Answers>JavaScript>

How can I find a readable stacktrace to debug TypeScript and JavaScript when using a bundler like Vite or Webpack?

How can I find a readable stacktrace to debug TypeScript and JavaScript when using a bundler like Vite or Webpack?

Richard C.

The ProblemJump To Solution

In your JavaScript or TypeScript application you might see an unusable stack trace for an error message like TypeError: Failed to fetch. Below is an example from a SvelteKit app that deliberately calls an incorrect URL with await fetch("");:

Click to Copy
entry.Bp8-PY4v.js:1 GET net::ERR_NAME_NOT_RESOLVED window.fetch @ entry.Bp8-PY4v.js:1 n @ 3.B4-FYFRq.js:5 3.B4-FYFRq.js:5 Fetch failed: TypeError: Failed to fetch at window.fetch (entry.Bp8-PY4v.js:1:1610) at HTMLButtonElement.n (3.B4-FYFRq.js:5:1465) n @ 3.B4-FYFRq.js:5

This error is shown in the console of the developer tools window of your browser. Although the error message gives line numbers for where the error occurred, the code at those lines is minified and unreadable.

You can encounter this problem in any JavaScript framework, like Angular, React, or Vue. It can also be caused by any JavaScript and CSS bundler, like Vite, Webpack, or Parcel.

The Solution

If you are running your application on your local machine for testing, using a dev server that comes with the bundler like vite dev, you will see more usable filenames:

Click to Copy
+page.svelte:39 GET net::ERR_NAME_NOT_RESOLVED callServer @ +page.svelte:39 +page.svelte:46 Fetch failed: TypeError: Failed to fetch at window.fetch (fetcher.js?v=fd13c2c9:65:10) at HTMLButtonElement.callServer (+page.svelte:39:27)

If you click on the error line in your browser it will open the corresponding file in a tab for you to see the exact cause.

However, if you have built and bundled your code for production you are unlikely to see such clear error messages. This is because a development server usually includes source maps — a link between the code running in the browser and the code you originally wrote — whereas a production build does not.

Excluding source maps from production is recommended because it decreases the amount of data users need to download. But if you have an error in production that you need to debug you can enable source maps temporarily. To do this you need to change your build settings and then build again and redeploy all files to your server.

This process differs from bundler to bundler but generally involves the following configuration changes.

If you use TypeScript, in tsconfig.json set the sourceMap field:

Click to Copy
{ "compilerOptions": { "sourceMap": true, ... } }

If you use Vite, in vite.config.ts set the sourcemap field:

Click to Copy
export default defineConfig({ build: { sourcemap: false, ... } })

If you use Webpack, in webpack.config.js set the devtool field:

Click to Copy
const config: webpack.Configuration = { devtool: source-map };

If you use Parcel, in .parcelrc set the sourceMap field:

Click to Copy
"sourceMap": true

Further Reading

At the time of writing, there is an open issue in Vite to add a top-level configuration setting to enable or disable all source maps. Until this is complete, and all plugin authors implement the setting, it is possible that source maps may not obey your configuration files request to turn them on or off.

  • ResourcesImprove Web Browser Performance - Find the JavaScript code causing slowdowns
  • ResourcesJavaScript Frontend Error Monitoring 101
  • logo
    Listen to the Syntax Podcast

    Tasty treats for web developers brought to you by Sentry. Get tips and tricks from Wes Bos and Scott Tolinski.


Loved by over 4 million developers and more than 90,000 organizations worldwide, Sentry provides code-level observability to many of the world’s best-known companies like Disney, Peloton, Cloudflare, Eventbrite, Slack, Supercell, and Rockstar Games. Each month we process billions of exceptions from the most popular products on the internet.

© 2024 • Sentry is a registered Trademark
of Functional Software, Inc.