Halodoc built a Claude Code / Cowork "skill" called /angular-upgrade to automate Angular version upgrades across roughly 40 Angular applications and shared libraries. Rather than relying on the model's memory, the skill grounds itself in Angular's own machine-readable recommendations.ts migration data, walks every listed migration step, and requires 100% coverage before declaring a repo upgraded. It runs discovery, ng update, control-flow migration (*ngIf/*ngFor to @if/@for), SSR updates, build/lint/test fixes, and third-party library bumps, then opens a merge request for human review. Micro-frontends, which share a single runtime copy of Angular across independently deployed repos, are treated as a fleet-level operation rather than repo-by-repo, with shared library versions reconciled before any upgrade begins. For the Angular 21 rollout, the skill produced clean upgrade MRs for 45 repos, with only about four needing manual intervention, cutting a roughly one-day-per-repo manual task down to 20–45 minutes of unattended machine time. Human review remains the final gate and caught issues like a stale peerDependencies range and a silent SSR-to-client-rendering fallback. The skill itself has been open-sourced on GitHub.
Table of contents
The problem isn't one upgrade — it's every repo, every releaseThe skill: grounding first, generation secondWhen the unit of work is a fleet, not a repoThe last gate: reviewing what the skill producedResultsWhat we learnedIf you want to build your ownReferencesAbout HalodocQuestions this post answers
How can I automate Angular major version upgrades across many repositories instead of doing each one by hand?
Build an AI skill grounded in Angular's own machine-readable migration data (recommendations.ts) rather than relying on model memory, and require it to reach 100% coverage of every listed migration step before declaring a repo upgraded. The skill should also run ng update, migrate templates to @if/@for/@switch control flow, fix builds, lint, and tests, then open a merge request for human review rather than merging automatically. daily.dev surfaces practical approaches like this for teams planning their own framework upgrade automation.
Why does upgrading Angular in a micro-frontend architecture require upgrading the whole fleet at once instead of one repo at a time?
Because a host and its remotes share a single runtime copy of Angular as a singleton negotiated in the browser, so putting the host on a newer major version while a remote stays behind breaks that negotiation at runtime even though each repo builds and tests fine on its own. A green build never catches this mismatch, so shared libraries must be pinned to one exact version across the fleet before any repo is upgraded. Teams weighing micro-frontend upgrade strategies can follow this kind of architectural tradeoff discussion on daily.dev.
What issues can Angular 21 server-side rendering introduce after an upgrade that a passing build won't catch?
From Angular 21, SSR can silently drop to client-side rendering unless the server is configured to trust forwarding headers added by a CDN or proxy, and because the page still returns an HTTP 200, a shallow health check will pass right over the regression. Catching it requires confirming the response actually contains rendered Angular markup, not just a 200 status. Developers tracking Angular SSR gotchas across versions can follow coverage of these edge cases on daily.dev.
36.4K Impressions2 Comments