I got tired of "works on my machine". We all know the feeling: you pull the latest code, run \`npm start\`, and it crashes. You check \`git diff\`, and it's empty. You haven't touched a thing.
So why is it broken?
Usually, it's "environmental drift" — stuff Git doesn't track.
• A dependency released a patch version that broke you (lockfile drift)
• You switched to Node 20 but the project needs 18
• You missed a new \`.env\` key a teammate added
I built *why-broke* to catch exactly this. It takes a "good state" snapshot of your environment (node version, lockfile hash, env keys). When a build fails later, it diffs the current state against the last known good state.
It’s open source: [Link to GitHub]
Install: \`npm i -g why-broke\`
Would love to hear what other "invisible" things break your builds.
Adityakammati•2h ago
I got tired of "works on my machine". We all know the feeling: you pull the latest code, run \`npm start\`, and it crashes. You check \`git diff\`, and it's empty. You haven't touched a thing.
So why is it broken?
Usually, it's "environmental drift" — stuff Git doesn't track. • A dependency released a patch version that broke you (lockfile drift) • You switched to Node 20 but the project needs 18 • You missed a new \`.env\` key a teammate added
I built *why-broke* to catch exactly this. It takes a "good state" snapshot of your environment (node version, lockfile hash, env keys). When a build fails later, it diffs the current state against the last known good state.
It’s open source: [Link to GitHub] Install: \`npm i -g why-broke\`
Would love to hear what other "invisible" things break your builds.