How I accidentally shipped my source maps (and why ignore files matter)

The Day I Shipped My Source Maps 😅

So, it happened. I was using Claude to help streamline an npm package update. In the hustle of moving fast, the AI "helpfully" updated my package but included .map files in the production build.

It wasn’t a disaster, but it was a wake-up call. When we automate our workflows with AI, we tend to overlook the "boring" configuration files. But those files are actually our human-critical safety nets.

The "Big Three" of Privacy & Performance

If you want to keep your builds clean and your source code structure private, you need to master these three files:

1. .gitignore 🛡️

Your first filter. It tells Git which files or folders to strictly ignore so they are never tracked or uploaded to your repo.

• What to include: node_modules, .env secrets, and local logs.

2. .npmignore 📦

Critical for library authors. If this file exists, npm uses it instead of .gitignore to determine what stays out of your published package.

• The Claude Lesson: If you don't define this, npm might default to your git rules, which often leads to accidentally publishing raw source or source maps (.map files) that you don't want in the final package.

3. .vercelignore ⚡

Essential for deployment efficiency. It tells Vercel exactly what to skip during the build process to speed up your CI/CD pipelines.

---

Pro-Tip: The "Files" Array

Instead of playing "Whack-a-Mole" with .npmignore, use the files property in your package.json. This acts as a whitelist, only allowing specific folders (like dist or build) to be published.

json
{
  "name": "my-cool-package",
  "files": [
    "dist"
  ]
}