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

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.

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:

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.

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.

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.

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.

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.