--- title: "How We Automated Angular Upgrades at Halodoc using AI" url: https://daily.dev/posts/how-we-automated-angular-upgrades-at-halodoc-using-ai-mmyjeplr8 source_url: https://blogs.halodoc.io/angular-upgrades-using-ai-skill type: article source: "Halodoc" published: 2026-08-21T08:16:38.441Z updated: 2026-08-21T08:17:10.681Z tags: ["webdev", "cicd", "angular", "claude-code"] reading_time: 20 upvotes: 16 comments: 2 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # How We Automated Angular Upgrades at Halodoc using AI **[Halodoc](https://daily.dev/sources/halodoc)** · 20 min read · 16 upvotes · 2 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions 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._ ## Community discussion Top comments from developers on daily.dev. **@agustinbarrientos** · 2 upvotes > The fleet validator should load the host with every remote and exercise Angular's runtime negotiation. A green build per repo can't catch singleton mismatches that appear only at composition time. **@rizzdev** · 2 upvotes > Grounding the skill in recommendations.ts is how a 45-repo Angular 21 sweep runs a 100% step gate. The coverage gate still signed off MRs where SSR fell back to the client and the page stayed 200. Treat those MRs as done and that silent fallback ships with the fleet ## Similar posts on daily.dev - [Automating Library Upgrades: Reducing Manual Effort](https://daily.dev/posts/automating-library-upgrades-reducing-manual-effort-xnryu16jc) · Halodoc · 1 upvotes · 0 comments --- Tags: [#webdev](https://daily.dev/tags/webdev), [#cicd](https://daily.dev/tags/cicd), [#angular](https://daily.dev/tags/angular), [#claude-code](https://daily.dev/tags/claude-code) [View this post on daily.dev](https://daily.dev/posts/how-we-automated-angular-upgrades-at-halodoc-using-ai-mmyjeplr8)