just-vibeVite · apply by default
/vite-upgrade
Upgrade Vite and plugins with compatibility and build checks
Use for a requested Vite version transition; deps handles general dependency selection.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select vite-upgrade from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv vite-upgrade, /just-vibe vite-upgrade and /jv:vite-upgrade in Claude. See shortcut setup and context examples.
/just-vibe:vite-upgrade Upgrade to the specified Vite version and verify framework-plugin compatibility./just-vibe:vite-upgrade Upgrade Vite while retaining an older framework plugin until a supported replacement exists./just-vibe:vite-upgrade Plan an upgrade with unavailable release-note access; do not guess removed options.What the agent does
- Read the target version's migration notes and check framework-plugin and Node compatibility.
- Update only the required dependency graph and lockfile, and adjust deprecated behavior.
- Compare dev refresh, production output and preview behavior with the previous version.
Inputs
- source/target version, framework/plugins, and runtime constraints.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Compatible Vite/toolchain upgrade and necessary config changes.
- Writes
- Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
- Mode
- Apply for a requested upgrade; source/target version, framework/plugins, and runtime constraints.
- Prerequisites
- Project manifests, lockfile, Vite/framework/plugin versions, and existing build scripts. Verify current version-specific documentation when changing configuration. Requested isolated verification may generate disposable build/cache artifacts; inspect their scripts first and preserve product files.
Expected output
- Upgrade patch with a version/peer matrix, configuration changes, dev/build/runtime checks and rollback steps.
How the work is checked
- Framework refresh and build both work; incompatible plugins are resolved or explicitly block the target version.
When to stop or clarify
- No unrelated major upgrades. If a required peer is unsupported, stop before presenting a broken combination as complete.
Handling missing context
- Infer
- Read manifests, lockfile, installed Vite/plugins, entry points, aliases, modes and current build scripts.
- Assume
- Preserve existing tooling and base-path conventions; in apply mode, make a local focused change when the brief identifies the behavior, and otherwise propose it.
- Ask
- Ask if the intended serving subpath or deployment target cannot be inferred and would change generated URLs; do not ask for versions present in the lockfile.
Technical guidance
- Evidence
- Read current/target migration notes, Node support, framework plugin peer ranges and config differences.
- Method
- Upgrade a coherent toolchain with the project's lockfile; remove obsolete options only after mapping their replacement behavior.
- Pitfall
- A passing install with ignored peer conflicts does not establish refresh or production compatibility.
- Check
- Verify dev refresh, build, preview and relevant SSR/test integration; report a plugin blocker instead of forcing an unsupported combination.
Situational decisions
When a required plugin has no compatible version: Stop at that compatibility boundary and propose a supported intermediate target.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.