I shipped lspforge on a Friday.
By Monday it was broken — and I hadn’t written a single bad line of code.
The Problem with Dependencies You Don’t Control
lspforge touches 11 repositories it doesn’t own: Claude Code, OpenCode, Copilot CLI, Kiro, Cursor, and six language servers. Any of them can ship a change that silently breaks my tool.
No webhook. No notification. No warning.
Users see: LSP not working. They blame lspforge.
The Monday Break
Claude Code shipped an update. Their LSP server now initializes before plugins load — a change in initialization order that introduced a race condition. My config stopped working overnight.
I found out when someone filed a GitHub issue.
The code was fine. The tests passed. The CI was green. The upstream project had changed its behavior, and there was no mechanism for me to know.
What Maintaining a Tool Actually Means
Not fixing your own bugs. Watching 11 repos for changes you didn’t make, testing releases you didn’t ship, patching code that worked perfectly yesterday.
The naive version of maintenance is “I’ll fix bugs as they’re reported.” That works when you control the dependencies. When you don’t, bugs get reported by users before you know they exist. Your first signal is a GitHub issue from a frustrated person whose workflow broke.
The realistic maintenance burden for lspforge:
- Track releases across 11 upstream repos
- Assess whether each release affects lspforge specifically
- Test the interaction between new upstream versions and lspforge’s config generation
- Ship fixes before the next person hits the break
Doing that manually is a part-time job. Every morning, checking 11 GitHub release pages.
The Fork in the Road
After the Monday break, I had a clear choice: make manual monitoring my morning routine, or automate it.
The automation is the next post in this series. But the decision framework is worth naming:
If a task is repetitive, predictable, and requires no judgment beyond “does this match a known pattern?” — automate it. Your attention is for the things that genuinely require it.
Monitoring release notes for breaking changes is exactly that kind of task. Every release note is either relevant to lspforge or it isn’t. Gemini can make that call faster and more consistently than I can at 9AM.
Shipping was the easy part. Maintaining it is the job.