Dev Encyclopedia
ArticlesTools

Get notified when new content drops

No spam. Just new articles, tools, and updates straight to your inbox.

Dev Encyclopedia

A reference for builders

Content

  • Articles
  • Tools
  • Contact

Connect

  • support@devencyclopedia.com
  • RSS Feed

© 2026 Dev Encyclopedia

Privacy PolicyTermsDisclaimer
  1. Home
  2. /
  3. Tools
  4. /
  5. SourceMapCheck
Free · Private · No uploads

Will your npm package leak source maps?

Paste your package.json and .npmignore to check before you build. Catches the configuration mistakes that lead to source map leaks, in seconds.

How SourceMapCheck works

  1. 1

    Paste your configuration files

    Paste your package.json (required), and optionally your .npmignore and tsconfig.json. The tool checks whatever you provide.

  2. 2

    Static analysis runs in your browser

    SourceMapCheck parses each file and checks for known risk patterns: missing files field, overly broad globs, absent .map exclusions, and sourceMap flags in TypeScript configs.

  3. 3

    Each risk is classified and explained

    Results are grouped by severity (pass, warning, fail) with a plain-English explanation of what is wrong and why it matters.

  4. 4

    Copy the suggested fix directly

    Every flagged issue includes a copy-ready configuration snippet: a corrected files array, a .npmignore line, or a tsconfig.build.json example.

  5. 5

    Get a CI automation snippet

    After the check, copy a ready-to-paste GitHub Actions step that runs npm pack --dry-run and fails the build if any .map files are detected.

What each result means

SourceMapCheck classifies each finding by severity so you can prioritise the most critical fixes first.

Fail

A configuration problem that will likely cause .map files to be published. The most common: no "files" field and no .npmignore exclusion for .map files. Fix these before publishing.

// package.json with NO files field
{
  "name": "my-lib",
  "main": "dist/index.js"
}
// Everything in the project directory ships, including dist/*.map
Warning

A pattern that could lead to source map leaks depending on your build setup. For example: .npmignore excludes .map files (good), but a blocklist approach is less safe than an allowlist. Or tsconfig.json has sourceMap: true, which may be a dev config and not your production build config.

// tsconfig.json with sourceMap enabled
{
  "compilerOptions": {
    "sourceMap": true,    // Risk: is this also your production config?
    "outDir": "./dist"
  }
}
Pass

The check found no risk. For example: a "files" field exists with no .map patterns, or sourceMap is disabled in your TypeScript config.

// package.json with explicit allowlist
{
  "name": "my-lib",
  "files": ["dist/**/*.js", "dist/**/*.d.ts"],
  "main": "dist/index.js"
}
// Only .js and .d.ts files ship — .map files are excluded by default

Configuration reference

The three configuration points that control whether source maps end up in your published package.

package.json "files" field (recommended)
{
  "name": "your-package",
  "files": [
    "dist/**/*.js",
    "dist/**/*.d.ts",
    "README.md",
    "LICENSE"
  ]
}
Allowlist approach: only listed patterns are published. Everything else (including .map files) is excluded by default.
.npmignore (fallback)
# Exclude source maps
*.map
**/*.map

# Exclude source files
src/
tsconfig*.json
Blocklist approach: everything is published unless explicitly excluded. Fails open if a new build step generates files in an unexpected location.
tsconfig.build.json (production builds)
{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "sourceMap": false,
    "declarationMap": false
  }
}
Keep source maps enabled in your dev tsconfig for debugging. Disable them in a separate production build config so .map files are never generated for the published artifact.

When to use SourceMapCheck

ScenarioWhat to pasteWhat you learn
First-time npm publishpackage.json + tsconfig.jsonWhether your default config will leak source maps
Inherited project auditpackage.json + .npmignoreIf the existing publish setup has gaps
Post-incident verificationAll three filesWhether your fix actually closes the source map leak
CI pipeline setuppackage.jsonGet a ready-to-paste GitHub Actions snippet
Monorepo package checkEach package's package.jsonWhich packages in the monorepo need a files field

Frequently Asked Questions

What does SourceMapCheck do?

SourceMapCheck analyzes your package.json, .npmignore, and tsconfig.json to detect configuration patterns that would cause .map files to be included when you run npm publish. It catches the problem at the config level, before you build or publish anything.

  • Checks the `files` field for missing allowlist or overly broad patterns
  • Checks `.npmignore` for missing .map exclusions
  • Checks `tsconfig.json` for sourceMap: true in production configs
  • Generates fix snippets you can copy directly into your project
How is this different from npm pack --dry-run?
npm pack --dry-runSourceMapCheck
When to useAfter buildingBefore building
Requires local projectYesNo (paste config)
Checks actual filesYesNo (checks config)
Suggests specific fixesNoYes, with copy-ready snippets
Generates CI snippetNoYes

SourceMapCheck is a faster first pass: it catches config-level mistakes before you spend time building. Use it alongside npm pack --dry-run, not instead of it. The tool reminds you of this after every check.

Does SourceMapCheck send my configuration anywhere?

No. All parsing and analysis runs in JavaScript inside your browser. Nothing leaves your machine. The tool has no backend, no API calls, and no analytics on what you paste.

💡 Tip

Once the page is loaded, SourceMapCheck works fully offline.

Should I use the files field or .npmignore?

Use the files field. It is an allowlist (fails safe), while .npmignore is a blocklist (fails open).

json
"files": ["dist/**/*.js", "dist/**/*.d.ts", "README.md", "LICENSE"]

With files, anything not explicitly listed is excluded by default. With .npmignore, new files generated by a changed build step are included unless someone remembers to add an exclusion rule.

How do I fix a source map leak if I already published a package?
  1. Run `npm unpublish <pkg>@<version>` if the version was published within the last 72 hours and has no dependents.
  2. Publish a new patch version with the .map files removed (add a files allowlist, rebuild, verify with npm pack --dry-run).
  3. Rotate any secrets that appeared in the leaked source code, since the npm registry caches tarballs and mirrors may have copies.
  4. Add a CI gate to prevent it from happening again (SourceMapCheck generates the GitHub Actions snippet for you).

⚠ Warning

Even after unpublishing, the tarball may exist in registry mirrors, CDN caches, and local node_modules of anyone who installed during the window. Treat leaked secrets as compromised.

Related reading

Guide

Source Maps Are Leaking Your Code

The full guide: what sourcesContent exposes, per-bundler config to disable it, and how to set up CI automation.

Guide

GitHub Actions Security

Secure your CI pipeline with the same patterns used for the npm pack check, plus secrets management and permissions hardening.