My fix was correct the whole time, my dev server just wouldn't say so

A design review flagged something simple: on a phone, the analytics consent prompt shows up immediately on load and covers the hero. Before you read a single word of the pitch, there’s a bottom sheet asking about cookies. The fix, once I knew what it was, took about ten lines: on phone widths, don’t reveal the prompt until the visitor scrolls, or after a few seconds if they never do. Desktop keeps its small corner card exactly as before.

That part went fine. What didn’t go fine was proving it worked.

This fix lives in a small shared package, not the site itself, one of a few @vdaluz/* libraries this site and its siblings pull in as a pinned tarball dependency. The release process says: pack the new version, install it locally into a consumer, test it for real before you tag anything. So I did. I edited the package’s source, ran npm pack, installed the tarball into this site with --no-save, and started poking at it in a real browser at phone width.

Nothing happened. The prompt showed up immediately, exactly like before my fix. I read my own code three times looking for the bug that wasn’t there.

It took a curl request to actually resolve it: fetch the exact file the dev server was serving, and read it. The bytes on disk had my fix. The bytes the server handed back over HTTP did not. Vite doesn’t watch node_modules for changes by default, it treats that whole directory as “third-party, won’t change,” which is normally a sane assumption and is exactly wrong the one time you’re deliberately editing something inside it to test a not-yet-tagged release. Clearing the build caches didn’t help either, because the running server already had the old content loaded in memory. The cache on disk was never the problem.

So I restarted the dev server. Same stale result. That’s the part that actually cost time: a process-stop call reported success, and I believed it. The old server was still very much alive, still listening, still answering every request with last week’s code, while my “new” server had quietly fallen back to the next open port and I kept testing against the wrong one. Nothing about the failure looked like “you’re talking to a zombie process.” It looked exactly like “your fix doesn’t work.”

What actually broke the loop: stop trusting that a request succeeding means you’re talking to the thing you think you’re talking to. I started grepping the served files directly for a marker unique to my latest edit, and checking for surviving processes by PID instead of trusting a tool’s own success message. Once I did that, the picture flipped instantly: served bytes matching the file on disk, no leftover process, prompt behaving exactly as designed. It had been correct since the first edit.

Shipped as @vdaluz/astro-opt-in-analytics v0.5.0: packed, tested, tagged, then bumped into this site once the tag was public. Confirmed live by grepping the actual production JS bundle for the new logic, not just loading the page and eyeballing it.