{
  "id": 7289764,
  "title": "The Deployment Failure That Only Shows Up on a Clean Clone",
  "url": "https://urgent.news/2026/09/14/the-deployment-failure-that-only-shows-up-on-a-clean-clone",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-14T09:56:37.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/talha_ramzan_3878156fea8c/the-deployment-failure-that-only-shows-up-on-a-clean-clone-5bo9"
  },
  "original_language": "en",
  "account": "For the past six months, my site has been gradually integrated with various tools, resulting in an increase from 112 to 138 tools. Each tool was added and tested individually, but crucially, each tool was not committed to the version control system immediately after being integrated. This lack of consistent atomic commits led to a deployment failure during a recent Vercel deploy.\n\nDuring an unrelated i18n issue fix, I made changes to a shared tool page router file, which compiled locally and was subsequently committed. However, the next Vercel deploy failed because the router file contained import statements and switch cases for seven tools whose actual component files had not been committed to git. These files existed only on my local machine and were not present in the clean Vercel clone, causing the build to fail at the first missing import.\n\nThe root cause of the issue was that the router file was treated as a single artifact, whereas it was actually a shared surface touched by multiple independently-completed features. Each tool added an import line and a switch case to the same file, but the component itself, its tools.ts entry, and its translations were separate, independently-committable units that did not move in lockstep. This lack of discipline in referencing shared files resulted in a landmine that exposed an already broken state.\n\nTo fix the bug, I removed the 14 orphaned lines (7 imports + 7 switch cases) referencing uncommitted components. However, the crucial verification was to ensure that the fix did not reintroduce the issue. I verified this by creating a clean clone of the repository, running the build process, and confirming that it succeeded without any errors. This clean-clone build is a stronger verification method, as it simulates the build environment that Vercel uses, without any local state or leftover files. Only through this method can you confidently confirm that the bug existed before your edit, rather than being caused by it.\n\nThe key takeaway is that shared files are only as reliable as the discipline around what can reference what. When a feature adds a line to a shared file before it is fully shipped, it creates a potential landmine. To avoid this, features should be committed as atomic units across every file they touch, such as the component, registration, content, and translations, all together in one commit. By following this approach, the likelihood of a deployment failure due to a shared file issue is significantly reduced.",
  "summary": "Six months of adding tools to my site, one page router file, and a lesson about the difference between \"works on my machine\" and \"exists in version control.\" The setup DukoTools just went from 112 to 138 tools. Most of that work happened gradually, build a component, wire it into the router, test locally, move to the next tool. Standard incremental development. What I didn't do consistently:…",
  "key_points": [
    "Six months of gradual tool integration increased tools from 112 to 138.",
    "Crucial deployment failure due to uncommitted tools in version control.",
    "Clean Vercel clone build succeeded after removing 14 orphaned import lines."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}