Menu

1 / 2

My Committed Bundle Went Stale: CI Rebuilt It and Never Compared

DEV Community: esbuild·HideyukiMORI·5 days ago
#Avzpfgqx
#devtoesbuild#devto#dev#build#output
Reading 0:00
15s threshold

I found out that a bundle committed to one of my repos had gone stale because an unrelated PR left my git tree dirty.

Not a test. Not a review. A dirty tree, noticed by accident.

The setup

nene-concierge is one of my self-hosted business tools. Its repo commits a built frontend artifact: public_html/admin/app.js , the admin bundle, produced by esbuild via npm run build . The public_html/ tree is the deployable root, generated files included.

Committing build output is a choice with a known tradeoff. I knew the tradeoff. I just wasn't paying for it.

What broke

An earlier refactor ( #178 / #179 ) added "type": "module" to frontend/package.json .

That one line changed esbuild's CJS interop output. Every helper call in the bundle went from __toESM(x) to __toESM(x, 1) . From that day on, the app.js sitting in main no longer matched what a clean build produces — a 573-insertion diff of pure drift.

Nothing failed. Type-check green. Lint green. Tests green.…

Continue reading — create a free account

Join HashtagPLUS to read full articles, follow hashtags, vote, and join the conversation.