JS Error Hub

How to generate hidden source maps in Vite

Exposing client-side source maps in production compromises proprietary logic and increases your application’s attack surface. This guide details how to configure Vite to output Source Map Generation & Stack Trace Debugging artifacts locally, then upload them to error tracking platforms without serving them to end users.

Implementing Vite Build Settings for Accurate Stack Traces ensures production stack traces remain fully symbolicated while keeping the original codebase private.

Key implementation points:

  • Prevents public access to unminified source code
  • Maintains 1:1 stack trace accuracy for error monitoring
  • Requires post-build upload to Sentry/Datadog/LogRocket
  • Uses build.sourcemap: 'hidden' in vite.config.ts

Symptom & Root Cause Analysis

Default Vite configurations often break production observability or leak source code. When build.sourcemap is left at false, error tracking services receive minified stack traces that are impossible to debug.

Conversely, setting it to true or 'inline' forces Vite to emit .map files directly into the public dist/ directory. The root cause lies in Vite’s asset pipeline.

Unless explicitly instructed otherwise, Rollup copies generated .map files alongside bundled JavaScript. Browsers automatically request these files when they encounter a //# sourceMappingURL= comment in the network response.

Attackers can then reconstruct your entire TypeScript or Vue component tree using standard browser dev tools.

Vite Configuration for Hidden Maps

Configure Vite to generate mapping artifacts without exposing them to the browser. The 'hidden' directive instructs Rollup to produce .map files in the output directory.

It simultaneously strips the source map comment from the final JavaScript bundles. Combine this with explicit output file naming to guarantee predictable paths for your CI/CD pipeline.

import { defineConfig } from 'vite';

export default defineConfig({
 build: {
 sourcemap: 'hidden',
 rollupOptions: {
 output: {
 sourcemapFileNames: 'assets/[name]-[hash].js.map'
 }
 }
 }
});

This configuration generates .map files in dist/assets/. It omits the //# sourceMappingURL= comment from bundled JavaScript, preventing browser fetches. The mapping data remains intact for offline processing.

Secure Upload & Cleanup Workflow

Generating hidden maps is only half the solution. You must automate their extraction and deletion to prevent accidental CDN deployment.

Error tracking platforms require exact file matches to resolve minified stack frames. Integrate a post-build script into your package.json to handle the upload and cleanup sequence atomically.

{
 "scripts": {
 "build": "vite build",
 "postbuild": "sentry-cli sourcemaps upload ./dist/assets --release $npm_package_version && find ./dist -name '*.map' -delete"
 }
}

The postbuild hook executes immediately after vite build. It uploads generated maps to the error tracking service using the build release tag.

It then recursively deletes all .map files from the distribution folder before deployment. This guarantees zero-trace production artifacts.

Minimal Reproduction & Verification

Validate your configuration by simulating a production error and verifying the network response. Deploy the built application to a staging environment.

Trigger a controlled runtime exception. Check your error tracking dashboard to confirm the stack trace resolves to original .ts or .vue line numbers.

Next, verify that the mapping files are completely inaccessible via public endpoints. Run the following curl command against your CDN or staging host:

curl -I https://cdn.example.com/assets/index-abc123.map

A 404 Not Found response confirms successful cleanup. If you receive a 200 OK, your deployment pipeline is still syncing .map files to the public bucket.

Common Mistakes

  • Using sourcemap: true instead of 'hidden': Generates a //# sourceMappingURL= comment in every chunk, causing browsers to request .map files publicly and exposing source code to network inspectors.
  • Deleting .map files before error tracker upload: Breaks the symbolication pipeline. Error monitoring services require the exact .map file matching the minified chunk hash to reconstruct original stack frames.
  • Ignoring sourcemapFileNames path mismatch: Default Vite output places maps in dist/assets/ but CLI tools often expect a flat directory or specific prefix. Mismatched paths cause upload failures or 404s during verification.

FAQ

Does ‘hidden’ sourcemaps affect local development debugging? No. Vite’s dev server uses inline sourcemaps by default. The build.sourcemap: 'hidden' setting only applies during vite build.

Can I serve hidden maps on a private CDN instead of deleting them? Yes, but requires strict IP allowlisting and authentication headers. Deleting post-upload is the industry standard for zero-trace production deployments.

Why do my error tracking tools still show minified code? Verify the uploaded .map hash matches the deployed JS chunk hash exactly. A mismatched release tag or incorrect upload path will prevent symbolication.