I came across an interesting issue where a `.map` file in an npm package exposed the original source code due to embedded sources (`sourcesContent`). It wasn't a breach, just a build artifact making its way into production, which raises some questions about JS tooling and best practices. I'm curious about how different people manage this with their production builds and published packages, especially regarding their bundler configurations and whether they inspect the final output before publishing. What approaches do you take?
5 Answers
I usually upload source maps to Sentry so we can debug better while keeping users protected. It’s a good way to retain the detail without exposing anything.
In most cases, I don’t minify npm packages so that users can debug them easily. Plus, they can find good PR opportunities through the code. The minification should usually happen in the user's production builds, not ours.
Great point! I think a lot of package authors don’t consider the implications of `.map` files in their published packages. Running `npm pack --dry-run` can help catch that, but many skip it.
For open-source projects, I think including source maps is fine. Minifying doesn’t really hide the code, and if it's open source, why not give users the full picture?
Exactly! But with proprietary code, it gets trickier. Just shipping minified versions isn’t enough when embedded sources leak the original code.
It's a balance. Enabling source maps in production can help debug issues since dev tools can reference the original source. But, it can also be risky if someone accesses those maps. Personally, I prefer to keep them off unless there's a solid reason to enable them.
True, if you're relying too much on source maps for debugging, it might indicate the error tracking isn't robust enough. What tools are you currently using for observability?
I generally strip source maps from the production bundle and upload them separately to Sentry during CI—best of both worlds! I also add `*.map` to my .npmignore to prevent them from being published. The real tricky part is ensuring the bundler config is switched from inline source maps during development to proper handling for production, since inline maps can accidentally end up in the final output.
That’s a common mistake! Automating a check in CI to catch any config mismatches before publishing could help a lot.
That sounds like a smart strategy! Do you upload them during your CI process or in a separate step once you're deployed?