update-deps
Update All Dependencies
Update all npm dependencies across the frontend (current repo) and backend projects. This skill handles the full update workflow including changelog review, code impact analysis, testing, and summarization.
Step 0: Ask for backend directory
Ask the user for the backend project directory path. Do NOT hardcode any path. Example prompt:
Please provide the backend project directory path (e.g.,
/path/to/backend).
Wait for the user's response before proceeding. Save the path as BACKEND_DIR for later use.
Step 1: Analyze current dependencies
Frontend (current repo)
- Run
pnpm outdated --recursivein the current repo root to identify all outdated dependencies. - Save the full output for later analysis.
Backend
- Run
pnpm outdated --recursiveinBACKEND_DIRto identify all outdated dependencies. - Save the full output for later analysis.
Present the user with a summary of how many dependencies are outdated in each project.
Step 2: Update dependencies
Strategy
Update in two phases to isolate issues:
Phase 1 — Patch and minor updates (safer):
From the pnpm outdated output, identify all dependencies where the update is a patch or minor version bump. Update them in batch:
- Frontend: For each patch/minor outdated package, run
pnpm update <package>@latest --recursivein the repo root. - Backend: For each patch/minor outdated package, run
pnpm update <package>@latest --recursiveinBACKEND_DIR.
Why
@latest? Both projects usesave-exact=true, so versions are pinned without^or~. Without--latest,pnpm updateonly resolves within the existing range, which for exact versions is a no-op.
Phase 2 — Major updates (requires careful review):
For each dependency with a major version update available:
- Identify the dependency name, current version, and latest version.
- Read the changelog (Step 3) before updating.
- Only update after confirming no blocking breaking changes.
- Use
pnpm update <package>@latest --recursiveto update specific packages.
Important pnpm workspace notes:
- The frontend project uses
pnpm cataloginpnpm-workspace.yamlfor some shared versions. If a dependency is managed via catalog, update the version inpnpm-workspace.yamlinstead of individualpackage.jsonfiles. - Both projects use
save-exact=true, so versions are pinned without^or~. - Check
patchedDependenciesinpnpm-workspace.yamlorpackage.json— if a patched dependency is being updated, verify the patch still applies or remove it if no longer needed.
Step 3: Review changelogs for major updates
For each dependency with a major version update, you MUST read the changelog before updating.
How to find changelogs
Use these methods in order of preference:
- npm registry: Run
npm view <package> repository.urlto find the repo, then check forCHANGELOG.mdor GitHub releases. - GitHub releases: Search
https://github.com/<owner>/<repo>/releasesusing WebFetch. - Web search: Use WebSearch to find
<package> changelog <old-version> to <new-version>.
What to look for
- Breaking changes: API removals, renamed exports, changed defaults, dropped Node.js version support.
- Deprecated features: Features being removed in future versions.
- Migration guides: Official upgrade instructions.
- Peer dependency changes: New or changed peer dependency requirements.
Document findings
For each major update, record:
- Package name and version change (e.g.,
foo: 2.x → 3.x) - Breaking changes summary
- Whether our code is affected (and how)
Step 4: Check affected code
For each dependency with breaking changes identified in Step 3:
- Use
Grepto find all imports and usages of the affected package across the relevant project (frontend or backend). - Read the files containing usages.
- Compare the usage against the breaking change description.
- If our code uses an affected API:
- Attempt to fix the code following the migration guide.
- If the fix is complex or risky, skip updating this dependency and note it in the summary.
- If our code does NOT use any affected API, proceed with the update.
Step 5: Run tests and checks
After all updates are applied:
Frontend
Run these commands sequentially in the repo root and capture results:
pnpm install
pnpm typecheck
pnpm test
pnpm lint
Backend
Run these commands sequentially in BACKEND_DIR and capture results:
pnpm install
pnpm typecheck
pnpm test
pnpm lint
Handle failures
- TypeScript errors: Read the error output, identify which updated dependency caused the issue, and fix the type errors. If unfixable, revert that specific dependency update.
- Test failures: Analyze the failure, check if it's related to a dependency update, and fix or revert.
- Lint errors: Run
pnpm lint:fixfirst. If issues persist, fix manually or revert the causing update.
Repeat the test cycle until all checks pass.
Step 6: Summary
Present the user with a comprehensive summary:
Update report
## Dependencies Updated
### Frontend
- <package>: <old-version> → <new-version> (patch/minor/major)
- ...
### Backend
- <package>: <old-version> → <new-version> (patch/minor/major)
- ...
## Skipped Updates (with reasons)
- <package>: <reason why not updated>
- ...
## Key Changelog Highlights
### Breaking Changes Applied
- <package> <version>: <what changed and how we adapted>
### Notable New Features
- <package> <version>: <brief description>
### Deprecation Warnings
- <package> <version>: <what's deprecated and timeline>
## Test Results
- Frontend typecheck: ✅/❌
- Frontend tests: ✅/❌
- Frontend lint: ✅/❌
- Backend typecheck: ✅/❌
- Backend tests: ✅/❌
- Backend lint: ✅/❌
Ask the user if they want to commit the changes.