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
Paste your configuration files
Paste your package.json (required), and optionally your .npmignore and tsconfig.json. The tool checks whatever you provide.
- 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
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
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
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.
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/*.mapA 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"
}
}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 defaultConfiguration reference
The three configuration points that control whether source maps end up in your published package.
{
"name": "your-package",
"files": [
"dist/**/*.js",
"dist/**/*.d.ts",
"README.md",
"LICENSE"
]
}# Exclude source maps
*.map
**/*.map
# Exclude source files
src/
tsconfig*.json{
"extends": "./tsconfig.json",
"compilerOptions": {
"sourceMap": false,
"declarationMap": false
}
}When to use SourceMapCheck
| Scenario |
|---|
| First-time npm publish |
| Inherited project audit |
| Post-incident verification |
| CI pipeline setup |
| Monorepo package check |
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
.mapexclusions - Checks `tsconfig.json` for
sourceMap: truein production configs - Generates fix snippets you can copy directly into your project
How is this different from npm pack --dry-run?
| npm pack --dry-run | SourceMapCheck | |
|---|---|---|
| When to use | After building | Before building |
| Requires local project | Yes | No (paste config) |
| Checks actual files | Yes | No (checks config) |
| Suggests specific fixes | No | Yes, with copy-ready snippets |
| Generates CI snippet | No | Yes |
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.
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).
"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?
- Run `npm unpublish <pkg>@<version>` if the version was published within the last 72 hours and has no dependents.
- Publish a new patch version with the
.mapfiles removed (add afilesallowlist, rebuild, verify withnpm pack --dry-run). - Rotate any secrets that appeared in the leaked source code, since the npm registry caches tarballs and mirrors may have copies.
- Add a CI gate to prevent it from happening again (SourceMapCheck generates the GitHub Actions snippet for you).