2026-04-01 | 🚀 Firing the Missiles: Deleting TypeScript 🗑️
🎯 The Mission
🧨 Today we deleted over twenty-five thousand lines of TypeScript automation code from this repository.
💡 Over the past several weeks, every TypeScript automation module had been carefully ported to Haskell. The Haskell binaries were already running in production, handling every scheduled task, every social media post, every blog generation run, and every Giscus comment injection. The TypeScript code was dead weight, and it was time to let it go.
🔬 The Audit
🔍 Before pulling the trigger, we conducted a thorough parity analysis to make sure we were truly ready.
📊 The analysis compared every TypeScript module against its Haskell counterpart. Here is what we found.
- ✅ Thirty-three TypeScript library modules in the scripts lib directory all had corresponding Haskell modules in the Automation namespace.
- ✅ Four platform modules for Twitter, Bluesky, Mastodon, and Open Graph metadata each had Haskell equivalents.
- ✅ Fourteen TypeScript CLI scripts were all subsumed by just two Haskell executables, run-scheduled and inject-giscus.
- ✅ Both GitHub Actions workflows, scheduled.yml and deploy.yml, were already downloading and running the pre-built Haskell binaries.
- ✅ Seven hundred nineteen Haskell tests were passing.
- ⚠️ One gap was identified. The broken-link-audit script has no Haskell equivalent. It is a post-deploy informational audit that samples pages from the live site and checks for broken internal links. Since it runs independently in the deploy workflow and is self-contained with zero imports from other automation modules, we kept it.
🗑️ What We Deleted
📦 The deletion was massive. Twenty-five CLI scripts and library entry points. Thirty-three core library modules. Four platform integration modules. Over twenty test files containing hundreds of test cases.
🔢 The final tally was eighty-four files removed and over twenty-five thousand lines deleted in a single commit.
🧹 The Cleanup
🔧 Deleting the code was only the beginning. We also cleaned up everything that referenced it.
- 📦 Five npm packages that existed solely for the automation scripts were removed from package.json: the Bluesky ATProto API, both Google Generative AI packages, the Twitter API v2 client, and the Mastodon client library.
- ⚙️ The scheduled.yml workflow was streamlined. Previously it ran npm ci to install all project dependencies into node_modules, even though the Haskell binary never used them. That step and its associated caching block were removed, saving CI time on every hourly run.
- 📖 The README was rewritten from top to bottom to reflect the new Haskell-first architecture. It now documents the Haskell library modules, the two compiled executables, the three GitHub Actions workflows, and the Haskell development workflow.
- 📋 Sixteen spec files were updated to replace TypeScript file paths with their Haskell equivalents. Dual TypeScript and Haskell tables were consolidated down to single Haskell entries. References to the TypeScript fallback and rollback instructions were removed.
- 📝 The AGENTS.md file was updated to reference the Haskell ObsidianSync module instead of the deleted sync-file-to-obsidian.ts script.
🧊 What Survived
🛡️ A few things intentionally remained.
- 🔍 The broken-link-audit.ts script and its library module stayed, along with their twenty-two passing tests. This is the sole remaining TypeScript automation script, used exclusively in the deploy workflow post-deployment audit.
- 🏗️ The benchmark-build.sh shell script stayed. It benchmarks Quartz builds and has nothing to do with the automation layer.
- 🌐 All Quartz TypeScript code in the quartz directory was completely untouched. Quartz is a Node.js static site generator and its TypeScript is a separate concern from the automation pipeline.
- 📦 Node.js and npm remain required for Quartz builds and the broken-link-audit. The package.json still lists all Quartz dependencies.
🎓 Reflections
🤔 Deleting twenty-five thousand lines of working, tested code takes a certain kind of confidence. The confidence came from three things.
- 🧪 First, the Haskell port was already running in production. Every hourly scheduled run was executing the Haskell binary. Every deploy was using the Haskell inject-giscus binary. This was not a theoretical migration; it was battle-tested.
- 📊 Second, the module-by-module parity analysis proved that nothing was missed. Every TypeScript function had a Haskell equivalent. Every feature was accounted for.
- 🏗️ Third, the architecture made the switch clean. The workflows already downloaded pre-built Haskell binaries. There was no interleaving of TypeScript and Haskell at runtime. The TypeScript code was completely inert.
🦋 The repository is now simpler, the CI is faster, and there is exactly one source of truth for the automation logic. The Haskell port is not a port anymore. It is the implementation.
📚 Book Recommendations
📖 Similar
- 🧱🛠️ Working Effectively with Legacy Code by Michael Feathers is relevant because it addresses the challenge of understanding, testing, and eventually replacing existing codebases, which is exactly what this migration entailed.
- 🗑️✨ Refactoring: Improving the Design of Existing Code by Martin Fowler is relevant because the entire Haskell port was a systematic refactoring from one language to another while preserving behavior.
↔️ Contrasting
- 🧑💻📈 The Pragmatic Programmer: Your Journey to Mastery by David Thomas and Andrew Hunt argues for incremental improvement and leaving code better than you found it, contrasting with the wholesale deletion approach taken here where the old code was simply removed rather than iteratively improved.
🔗 Related
- 🐣🌱👨🏫💻 Haskell Programming from First Principles by Christopher Allen and Julie Moronuki is relevant because the entire automation layer is now written in Haskell, and understanding the language deeply is essential for maintaining this codebase.
- Release It! by Michael Nygard is relevant because the migration strategy of running both implementations in parallel before cutting over is a classic production reliability pattern.