JHipster 9.1.0 just dropped. For years, that sentence put a specific knot in Sam's stomach — version bumps meant a git-merge adventure, surprise conflicts, and the nagging fear of a file you'd customized getting quietly overwritten. OtakuShelf is on 9.0.0 and Sam actually likes it the way it is. So the real question isn't "how do I upgrade," it's "should I, and what will it cost me?" The agent can answer both before a single file changes.
Sam starts by scoping it:
How risky is upgrading
/Users/sam/projects/otakushelf
to JHipster 9.1.0?
The upgrade_advisor
tool reads OtakuShelf's .yo-rc.json
and entity configs and reports back the shape of the jump:
One thing Sam appreciates: the advisor doesn't invent a list of breaking changes. A minor release shouldn't have many, but for the authoritative word it points Sam at the release notes rather than bluffing. It gives the facts and the scope; the specifics live where they actually live. For a minor, low-risk bump, the verdict is "go for it" — but Sam still wants to see the damage first.
Show me what upgrading OtakuShelf to 9.1.0 would change.
This is the one Sam wishes had existed years ago. preview_upgrade
regenerates OtakuShelf's own model in an isolated temp copy using generator 9.1.0 — fetched on the fly via npx generator-jhipster@9.1.0
, so Sam doesn't even have to install it globally first — and diffs the result against the current project:
Upgrade preview → generator-jhipster@9.1.0:
+1 added -0 removed ~14 modified
Added (1): ...
Modified (14): build dependency bumps, a few Vue components, Liquibase config, ...
OtakuShelf itself is never touched — it's a diff against a throwaway regeneration. And there's an honest caveat the tool states plainly: that modified
list mixes two things — changes the new generator makes and files Sam has customized. Telling them apart is the real work of any JHipster upgrade. The difference now is that Sam sees the whole list up front, on a calm afternoon, instead of discovering it mid-merge at 11pm.
Fourteen modified files, mostly dependency bumps and regenerated boilerplate, nothing touching Sam's hand-edited Franchise view. This is a Tuesday, not an adventure.
Notice what the MCP did not do: it didn't run the upgrade. The official jhipster upgrade
is a git-based merge, and this server stays deliberately out of your git — so it previews instead of merging. With the diff in hand, Sam drives the actual change through a normal workflow: commit the current state, run the upgrade (the agent can kick off jhipster upgrade
through the escape hatch, or Sam runs it by hand), and resolve the handful of spots the preview already flagged. Because Sam committed first and knew the blast radius in advance, the merge is a quick, confident review rather than a leap of faith.
A ./mvnw verify
and an npm test
later (the MCP told Sam those commands back in part 1, remember), OtakuShelf is happily running on 9.1.0.
Four sittings ago, OtakuShelf was an empty folder and a vague idea, and Sam was skeptical about letting an AI near a generator. Now there's a paginated, DTO-backed catalog of manga and anime — scaffolded, grown, polished, and version-bumped — and at no point did the agent's involvement mean less control. The pattern that emerged was simple and stuck:
The MCP didn't replace Sam's JHipster judgment. It deleted the friction around it — the JDL typing, the CLI prompts, the upgrade dread — and left the decisions where they belong.
That's the shelf built. Time to actually add some manga to it. 📚
Want the precise arguments and edge cases behind any of this? The story motivates; the docs specify — start with the tools reference. And the server itself: jhipster-mcp on npm.