Skip to content

Features

Source maps: read production errors in your own code

Production builds are minified, so a raw stack trace points at mangled names in a bundle. Upload the source maps your build already produces and every frame is shown as the original file, line, column and function.

All Buglapse features

Source maps

Readable stack traces without publishing your code

  • Original files and lines

    Frames are decoded automatically on the error and issue pages, with the source lines around the failing one.

  • A plugin for your bundler

    One plugin handles generating and uploading the maps as part of the build for Vite, Rollup, webpack, Rspack and esbuild — no separate CI step to maintain.

  • Tied to a release

    Maps are uploaded for a specific release, so an error from last week's build is decoded with last week's maps, not today's.

  • Stable grouping

    Frames are decoded before errors are grouped, so the same bug stays in the same issue even though every build renames the minified files.

How it works

Set up source maps

  1. 1

    Set a release in the SDK

    Pass a release to init: a version, a git commit or a build number that identifies one deploy.

  2. 2

    Add the bundler plugin

    Give it the same release and a personal access token kept in a build secret. Maps are uploaded during the build.

  3. 3

    Read decoded frames

    The next error from that release shows original files and lines. Nothing changes on the pages themselves.

vite.config.ts
import { defineConfig } from 'vite'
import { sourcemaps } from '@buglapse/bundler-plugin/vite'

export default defineConfig({
  plugins: [sourcemaps({
    url: 'https://app.buglapse.com',
    authToken: process.env.BUGLAPSE_AUTH_TOKEN,
    org: 'acme',
    project: 'acme-web',
    release: process.env.BUILD_RELEASE,
  })],
})

In detail

Matching and security

How a frame finds its map

Decoding depends on two things matching exactly: the release stamped on the error and the name of the minified file the frame points at. If either differs, the frame is simply left as it is rather than reported as a failure, so the first thing to check when a trace stays minified is that the build and the SDK use the very same release string. Without the plugin, maps can be uploaded from CI through the API.

Your source stays private

Maps are uploaded to Buglapse and are not served to browsers, so you do not need to publish them next to your bundles. Uploads are authorized by a personal access token with a dedicated scope. It is separate from the project DSN and belongs only in a build or CI secret, never in client-side code. On plans with code links, frames also link to the file in your GitHub or GitLab repository.

On each plan

Compare all plans
On each plan
Free Pro Team
Source mapsIncludedIncludedIncluded
Largest source map10 MB30 MB50 MB
Stack frames linked to your repositoryIncludedIncludedIncluded

FAQ

Common questions

Still have questions?

Drop us a line — we'll help with setup, plans or self-hosting.

Contact us

or email hello@buglapse.com

Which bundlers are supported?
The plugin has entry points for Vite, Rollup, webpack, Rspack and esbuild. Frameworks built on webpack, such as Next.js, use the webpack one.
Do I have to make source maps public?
No. They are uploaded to Buglapse during the build and can be removed from the files you deploy.
Why is a stack trace still minified?
Almost always because the release of the error does not match the release the maps were uploaded for, or the file name differs. Use one release value for both.

See also

Error tracking

Every error grouped into one issue with a readable stack trace, breadcrumbs, the steps to the error and the affected users.

Learn more: Error tracking

JavaScript

Error monitoring, tracing, logs and session replay for browser JavaScript, with any framework.

Learn more: JavaScript

Ready to see what's happening in your app?

Create a project on the free plan and send your first event in a couple of minutes.

Still have questions? Email hello@buglapse.com