I Vibe-Coded My Way Out of Angular Upgrades

The npm ci failure is the part that makes this interesting. An AI agent can migrate Angular APIs correctly and still miss the contract between the lockfile, peer dependencies, and the publishing environment.

For example, in a library migrating from Angular 17 to 18, updating @angular/core and @angular/compiler-cli isn't enough if @angular-devkit/build-angular, the TypeScript version, and the library's peerDependencies still target incompatible ranges. The app may compile locally because of an existing node_modules tree, then fail in CI with a clean install or break consumers installing the published package. I'd make the skill validate those dependency constraints, run npm ci from a clean checkout, build the library in production mode, and test the packed tarball in a separate Angular consumer project. That last step catches problems a successful workspace build can easily miss.

The part I'd steal is that each fix came from a real failure. The part I'd worry about is the trim from 1,252 to 701 words.

When I've cut agent instructions down, the line that goes first is usually the one that looks redundant but was there because of one specific bad day. Something like "run npm ci before calling it done" reads like filler six weeks later.

Do you keep the three failures (lockfile drift, the npm version for trusted publishing, the big migration jump) as a checklist the skill has to pass after every edit? Otherwise the next "make it shorter" pass might quietly delete one of them.

The most valuable part of this workflow is that the skill improved after each real failure. I’d take that one step further by making the validation environment reproducible: pin the Node.js and npm versions, start from a clean checkout, and run the same checks locally and in CI. Otherwise, the agent may fix the symptom in one environment without identifying the underlying version mismatch. It could also record which checks passed and which remain unverified, so “upgrade complete” means more than a successful build. That turns the skill from a migration script into a repeatable maintenance process that can be trusted across projects.

Oh, this is something I should probably send to the team maintaining the Angular component library we're forced to use! 😂 Upgrading Angular itself is already a pain in the ass, but upgrading that library is a whole new level of nightmare! I swear, sometimes I think they assume nobody ever upgrades it, because they make changes like renaming (close) to (closeDialog) between versions, only to rename it back to (close) in the next one. 😂 So yeah, let them give it a try and burn some tokens! 😁

Great post about agent skills! You are a great developer who succeeded in updating Angular using skills. 👍 I am using my handmade skills and keep updating it to write my AI Avatar README, but it always fails even though AI Avatar is already at v25. 🤣

Great job!

@gramli Fair - and I would narrow my claim: the skill should not enforce its own pins, but it can enforce the project's declared requirement. Read engines / .nvmrc / packageManager from the repo, check the running Node/npm against it as a preflight, and fail with "this project requires Node X, you have Y". No pin injection, but the constraint is read from the project and surfaced early. That was the actual point of engine-strict: it turns an opaque E404 from trusted publishing into a named, early failure - and the version mismatch stops being a supply-chain mystery.

The interesting part is that the upgrade itself wasn’t the hardest problem. It was catching the things that only show up outside the local environment. Adding npm ci as a validation step seems like a small change, but it can save a lot of debugging later.

One validation I'd add from bitter experience with ng update: after the migration schematics run, git diff --stat alone hides which schematics actually fired. I've had a schematic silently not apply because a version gate was missed, and the diff just looked 'fine' until runtime. I now make agents record the executed migrations (a small log on the upgrade branch works) so the reviewer sees 'which codemods ran', not just the resulting diff. Pairs well with your clean-install check — one verifies the environment, the other verifies the migration actually happened.

making npm ci a hard gate before the agent can say done is the best move in here. most agent upgrade failures i have seen are the agent grading its own work on a dev server that is already warm. a clean install plus a production build in a fresh container catches lockfile drift, peer dep conflicts and node version mismatches in one shot.

the 1,252 to 701 word trim tracks with what we saw too, the long instructions were mostly hedging and the validation steps were the part that survived.

did the skill ever stall on the 19 to 22 jump, or did it step one major at a time?