Source Maps Are Leaking Your Code: How to Stop It in Your npm Packages

A source map is a small JSON file that maps your minified, bundled production JavaScript back to the original source code you actually wrote. They exist so that when an error happens in production, your error tracker can show you a readable stack trace instead of a pointer into a single 2 MB line of minified code.

The problem is one specific field inside that JSON: sourcesContent. When populated, it contains the complete original source files, every line, every comment, in plain text, embedded directly inside the map. If that map file ends up somewhere public, so does your entire original codebase.

This is not a hypothetical. A widely covered packaging mistake earlier this year made this exact failure mode the talk of the JavaScript ecosystem for a week: a published npm package included a source map with sourcesContent populated, and within hours the original TypeScript source had been fully reconstructed and mirrored publicly. The mechanism was identical to dozens of smaller, less-publicized incidents that happen regularly.

Here is how to make sure it does not happen to your project.

A source map looks roughly like this:

The sources array lists original file paths. The sourcesContent array, when present, contains the full text of each of those files. That second array is the part that turns a debugging convenience into a code disclosure risk.

If a .map file with sourcesContent populated ends up publicly accessible (published to npm, deployed to a public web server, left in a public CDN bucket) anyone who finds it can reconstruct the entire original codebase. No exploit required, just a downloaded file.

The mappings field is a Base64 VLQ-encoded string that records position relationships between the bundled output and the original sources. Each segment maps a specific character position in the minified file to a line, column, source file index, and original position.

On its own, mappings tells a tool where each piece of code came from, but it does not reveal what the original code looked like. That is the job of sourcesContent. Without it, someone would need access to your source files on disk to make the mappings useful. With it, the source map is entirely self-contained, no disk access needed.

This distinction matters because some developers assume that since the mappings field is encoded, it obscures the source. It does not. The encoding is for compression, not confidentiality. And when sourcesContent is present, even the encoding is irrelevant because the raw source sits right there in plain text.

The damage from a leaked source map goes well beyond someone reading your variable names. Here is a concrete picture of what becomes available when a source map with sourcesContent is publicly accessible.

Extracting this data is trivial. A single command with a tool like source-map (an npm package specifically designed for parsing source maps) can dump every original file to disk:

Anyone who downloads your published package can run this script in under a minute. There is no authentication, no rate limiting, and no way to revoke the data once the package version is published.

The fix depends on your build tool, but the principle is the same everywhere: do not generate sourcesContent in artifacts that leave your build environment.

Setting devtool: false is the safest option. If you need source maps for error tracking (covered below), use hidden-source-map instead. It generates the file but omits the //# sourceMappingURL comment that tells browsers where to find it.

One common mistake with Webpack is using nosources-source-map and assuming it is safe. This option generates a source map that includes file paths and line mappings but strips out sourcesContent. While that does remove the raw source, the file paths and position data can still reveal your project structure and help an attacker understand your codebase layout. For npm packages, devtool: false remains the correct choice.

When building a library with Vite in lib mode, the sourcemap option works identically. However, double-check your Rollup config if you are using Rollup directly, since Rollup's output.sourcemap option defaults to false but can be overridden by plugins like @rollup/plugin-typescript which may inject their own source map settings.

esbuild supports several source map modes: linked (default when enabled), external, inline, and both. For npm packages, set sourcemap: false. If you need maps for error tracking, use external and handle the map files in your CI pipeline before publishing.

Keep source maps enabled in your development config; disable them only in the production build config. Using two separate tsconfig files for dev vs build keeps this explicit rather than relying on an environment variable check that is easy to forget.

Note that declarationMap is a separate setting from sourceMap. Declaration maps (.d.ts.map files) map your type declarations back to the original TypeScript source. While less risky than full source maps (they only reference type positions), they still expose file paths and can contain sourcesContent in some configurations. Disable both for published packages.

Bun generates source maps by default. This is the detail that catches people off guard, since most bundlers default to maps-off in production mode. Pin the flag explicitly rather than relying on documented default behavior:

Next.js generates source maps for server-side code by default but not for client-side bundles. If you have enabled client-side source maps (via productionBrowserSourceMaps), make sure you understand the implications:

Setting productionBrowserSourceMaps: true is one of the most common ways source maps accidentally end up on public-facing websites. Once deployed, every visitor's browser can fetch and parse those maps. Keep this at false and use the hidden-source-map pattern with your error tracker instead.

Before every publish, run:

This prints exactly what would be included in the published tarball, without actually publishing anything. Read the file list. If you see any .map files in there, stop and fix your config before publishing.

This one command, run as a habit before every release, would have caught the high-profile incident mentioned earlier before it ever reached the registry.

For pnpm users, the equivalent is pnpm pack --dry-run. Yarn does not have a direct equivalent, but you can run yarn pack --dry-run in Yarn v1 or inspect the tarball contents after yarn pack in Yarn v3+. Regardless of your package manager, the principle is the same: inspect before you publish.

Relying on .npmignore to exclude .map files is a blocklist approach: it fails open. If someone adds a new build step that generates files in an unexpected location, .npmignore will not know to exclude them unless someone remembers to update it.

An explicit files field in package.json is an allowlist: it fails safe. Only what is explicitly listed gets published, regardless of what else exists in your working directory:

Notice what is absent from that list: *.map. Anything not explicitly included simply does not ship, no matter what your build process generates. Check your own package.json against these risks instantly with SourceMapCheck.

Even with a files field, certain patterns can accidentally include source maps. Watch out for these:

The first pattern (dist/**) matches every file in the dist directory, including .map files. The third pattern includes src, which ships your raw TypeScript source directly, defeating the purpose of minification entirely. Always use specific file extensions in your allowlist.

Manual habits get forgotten under deadline pressure. The reliable fix lives in CI, not in memory. Add this as a CI gate using the same workflow pattern you use for other security checks:

Add this as a required step before any publish job. It fails the build automatically if a .map file would be included, so no human has to remember to check.

The basic grep check catches .map files by extension, but a more robust script can also look for inline source maps and sourcesContent embedded in non-map files:

This extended check catches three categories of leaks: standalone .map files, inline source maps (where the entire map is Base64-encoded inside a data: URL at the end of the JS file), and any stray sourcesContent fields in JSON files within your dist directory.

In a monorepo setup, each publishable package has its own build config and its own package.json. The source map risk multiplies because a single misconfigured package in a workspace can leak code while every other package is correctly configured.

The most common monorepo failure mode is a shared build config that works correctly for applications (which are deployed, not published) but generates source maps for libraries (which are published to npm). Applications and libraries have different threat models, so they need different build settings.

The prepublishOnly script runs automatically before npm publish. Pointing it at a shared validation script means every package in the workspace gets the same pre-publish check. If you use a tool like Turborepo or Nx, add the source map check as a pipeline dependency of your publish task so it runs automatically across all packages.

There is a legitimate reason to generate source maps in production: readable stack traces in your error tracking tool. The safe pattern is to generate them, upload them privately to your error tracker during the build, then delete them before the final artifact ships:

The map files exist briefly during the build pipeline, get uploaded to a private destination, and never appear in the artifact that actually ships. Your error tracker can still de-minify stack traces using its private copy; nothing public-facing ever has access to your original source.

Each error tracking service has its own CLI and upload pattern. Here are the most common ones:

The critical step that is easy to forget: <strong>delete the map files after uploading</strong>. If your CI pipeline does not explicitly remove them, they can end up in your deploy artifact or your npm package. Add the deletion as an explicit step rather than relying on a post-build cleanup script.

DepScan audits what you are installing; this guide covers what you might be accidentally publishing. The same build-hygiene discipline that Bumblebee enforces at the machine level applies to your own published packages.

Before every npm publish, walk through this checklist. It takes under a minute and covers the most common source map leak vectors:

If you discover that a version of your package has already been published with source maps included, the damage control process depends on how quickly you catch it.