Do you also hate upgrading Angular versions? Because I do. I maintain a few open-source projects, and upgrading Angular is probably my least favori...
For further actions, you may consider blocking this person and/or reporting abuse
The
npm cifailure 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/coreand@angular/compiler-cliisn't enough if@angular-devkit/build-angular, the TypeScript version, and the library'speerDependenciesstill target incompatible ranges. The app may compile locally because of an existingnode_modulestree, then fail in CI with a clean install or break consumers installing the published package. I'd make the skill validate those dependency constraints, runnpm cifrom 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.Good points. Actually, that first
npm cifailure is exactly why I added clean-install validation to the skill. It creates a fresh temporary copy withoutnode_modules, so it doesn't rely on existing dependencies.I also tested it on a published Angular library with its own demo application. The skill upgraded Angular, I tested the demo, and then published the updated library.
Testing the packed package in a separate consumer project makes sense for library release validation, but I'd say that's beyond the scope of a general Angular upgrade skill. π
That makes sense. Testing the demo app is a much better signal than just checking whether the library builds after the upgrade. One edge case I'd still watch for is Angular's partial-Ivy compatibility and peer dependency ranges. For example, a library can work perfectly in its own demo while its published
peerDependenciesaccidentally exclude an Angular version that should be supported, or while its packaging configuration omits a secondary entry point. Those are release-contract issues rather than upgrade failures, though, so I agree they don't necessarily belong in the core skill. Keeping the upgrade workflow focused and leaving deeper package-release checks as an optional step sounds like the right boundary.Yes, I agree, thanks for the detailed feedback and suggestions.
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.
Thanks for the ideas! That's actually how I approached it. The skill prefers the latest Node.js LTS compatible with the target Angular version and project requirements, rather than pinning a specific version for every project.
It also checks the CI configuration for the npm version, runs
npm ciin a fresh temporary directory withoutnode_modules, and reports which validation steps passed or couldn't be verified.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! π
Nice,
(close)to(closeDialog)and then back to(close)? That sounds like pure evil! πππSo what you actually need is a separate skill for upgrading that specific library?! π€£
Exactly! π Every time we upgrade that library, we joke that they're doing it on purpose, just to make sure we'll have jobs for the rest of our lives! π€£
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. π€£
Haha, the struggle of keeping AI skills up to date is real! ππ Turning a repetitive Angular upgrade into a one-week achievement is genuinely impressive. Itβs fascinating how the right skills can transform AI from a coding assistant into a reliable workflow partner. Now Iβm curiousβwhat do you think made the biggest difference: the skillβs instructions, the workflow, or the way you guided the agent? π€π
Thanks! I'd say the workflow, especially the validation steps. Clear instructions are important, but they don't guarantee the agent will get everything right. The first version looked promising, but then
npm cifailed in CI. That's when I realized the skill needed better validation.So I think the biggest difference came from testing it on real projects, finding what failed, and improving the skill along the way.
Thanks! π Haha, sounds like your README skill is giving you more trouble than my Angular upgrades! π€£
Great job!
π€£π€£
π€£π€£
Of course @sylwia-lask π
hahahahahahahha πππ
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.
Good question. Actually, both frontend upgrades were done using the final, shorter version of the skill:
The library upgrade, angular-mydatepicker PR #12, was done before I shortened the instructions. That was actually the project where I originally built and refined the skill based on those failures.
So the shorter version has been tested on real projects, but you're right that this doesn't guarantee every original edge case is still covered. Keeping a regression checklist for future changes is actually a good idea.
That's a better test than my worry: two real upgrades on the short version. If a third one ever breaks, the regression checklist doubles as a record of what the trim dropped, which is the part I'd most want to see. Nice PRs.
ε¦ε°δΊ