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

Richard C.

—May 15, 2024

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("https://doesnotexist.com");:

entry.Bp8-PY4v.js:1
    GET https://doesnotexist.com/ 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:

+page.svelte:39
    GET https://doesnotexist.com/ 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:

{
  "compilerOptions": {
    "sourceMap": true,
    ...
  }
}

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

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

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

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

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

"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.