feat(migrate): upgrade existing Vite+ projects across versions#1891
Draft
fengmk2 wants to merge 90 commits into
Draft
feat(migrate): upgrade existing Vite+ projects across versions#1891fengmk2 wants to merge 90 commits into
fengmk2 wants to merge 90 commits into
Conversation
✅ Deploy Preview for viteplus-preview canceled.
|
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
fengmk2
added
test: e2e
fengmk2
force-pushed
the
rfc/migrate-upgrade-path
branch
from
feb8068 to
5090afc
Compare
vite-plus
@voidzero-dev/vite-plus-core
@voidzero-dev/vite-plus-prompts
@voidzero-dev/vite-plus-cli-darwin-arm64
@voidzero-dev/vite-plus-cli-darwin-x64
@voidzero-dev/vite-plus-cli-linux-arm64-gnu
@voidzero-dev/vite-plus-cli-linux-arm64-musl
@voidzero-dev/vite-plus-cli-linux-x64-gnu
@voidzero-dev/vite-plus-cli-linux-x64-musl
@voidzero-dev/vite-plus-cli-win32-arm64-msvc
@voidzero-dev/vite-plus-cli-win32-x64-msvc
@voidzero-dev/vite-plus-darwin-arm64
@voidzero-dev/vite-plus-darwin-x64
@voidzero-dev/vite-plus-linux-arm64-gnu
@voidzero-dev/vite-plus-linux-arm64-musl
@voidzero-dev/vite-plus-linux-x64-gnu
@voidzero-dev/vite-plus-linux-x64-musl
@voidzero-dev/vite-plus-win32-arm64-msvc
@voidzero-dev/vite-plus-win32-x64-msvc
commit: |
fengmk2
force-pushed
the
rfc/migrate-upgrade-path
branch
from
5090afc to
732edd6
Compare
Member
Author
This comment was marked as outdated.
This comment was marked as outdated.
fengmk2
force-pushed
the
rfc/migrate-upgrade-path
branch
from
7a1d2de to
c68f763
Compare
fengmk2
force-pushed
the
rfc/migrate-upgrade-path
branch
from
1bba44c to
911881e
Compare
A project skill that drives and captures vp's interactive clack prompts in a tmux session, with a STOP_AT mode that double-captures a prompt to detect a spinner animating beneath it (how the Node-upgrade confirm overlap was found). Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
fengmk2
force-pushed
the
rfc/migrate-upgrade-path
branch
from
9849ce1 to
d9c74ff
Compare
fengmk2
commented
Jun 28, 2026
Match the docker-image workflow's method: build the sticky bridge-version comment as a github-script line array (so the fenced JSON block can't collide with YAML block-scalar indentation) and post it via a marker-based listComments -> updateComment/createComment, replacing the gh api + sed shell logic and the now-inlined .github/bridge-comment-template.md. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
…checks - migration.rs: extract a shared resolved_if_supported helper so the NAPI entry point and the test-only mirror verify the resolved version against the supported range with one implementation, and correct the inaccurate "shared by the NAPI entry point" doc on the test helper. - format.ts: isExistingFile uses a single statSync().isFile() in try/catch instead of existsSync + statSync (two stat syscalls per changed file). - vitest-ecosystem.ts: compute the required-vitest-peer dependency scan lazily (requiredVitestPeer ?? scan()) so the cheap ecosystem-dep check short-circuits it, matching the file's existing precomputedScans idiom. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
… rules Per PR review: the migrate-rules guide does not need to spell out the interactive vs --no-interactive confirm behavior for the Node.js upgrade. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
Replace the manual `curl POST /-/refs` with the bridge's publish-preview action (fengmk2/pkg-pr-registry-bridge), which downloads each pkg.pr.new package, re-packs the two preview packages, uploads them with matching integrity, and registers the ref, the CPU work that previously ran in the bridge's GitHub webhook. SHA-pinned to bridge main. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
…mment The bridge comment rebuilt 0.0.0-commit.<sha> from the raw sha; read the publish-preview action's `version` output instead so the version scheme has a single source of truth. Also correct the line-array comment to name the real reason (avoid escaping the inline backticks and fenced json block). Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
The bridge moved from fengmk2/pkg-pr-registry-bridge (render.vip) to voidzero-dev/pkg-pr-registry-bridge (void.app). Per the new docs/ci-setup.md, switch the publish workflow to the root action voidzero-dev/pkg-pr-registry-bridge and the void.app bridge URL, and update the test-pkg-pr-new-migrate helper's bridge registry to void.app. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
Projects commonly gitignore .npmrc, so the bridge registry the helper writes was silently dropped from the commit and the project's CI resolved the commit build from the default registry (which has no 0.0.0-commit.<sha>), failing the supply-chain policy check with ERR_PNPM_TARBALL_URL_MISMATCH. Force-stage .npmrc (and .yarnrc.yml for Yarn Berry) so the bridge registry reaches the project's CI. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
The existing-Vite+ upgrade (bootstrap/re-pin) path did not add a direct `vite` devDep for pnpm, so an already-Vite+ pnpm project being re-pinned kept no direct vite and pnpm's autoInstallPeers fabricated a separate upstream vite to satisfy the vitest-ecosystem peer, splitting vite-plus/vite/vitest (`vp why -r vite` then shows two instances). reconcileVitePlusBootstrapPackage now calls ensureDirectViteForPnpm (the same helper the full-migration path uses in rewriteRootWorkspacePackageJson / rewriteMonorepoProject), so the root and every member that depends on vite-plus gain a direct `vite: catalog:`. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
pnpm evaluates a native optional dependency's engines.node against the FLOOR of the project's declared Node range (e.g. devEngines.runtime), not the running Node. A pin like ">=24" or bare "24" overlaps the supported range (^20.19.0 || ^22.18.0 || >=24.11.0) but its floor 24.0.0 is below the minimum, so pnpm skips the @voidzero-dev/vite-plus-* native packages and the toolchain fails with "Cannot find native binding". The Node-version upgrade now uses a floor-based check (was overlap via allows_any) and normalizes all three pins independently: .node-version to the concrete latest release of the major, devEngines.runtime and engines.node to an open >=<supported minimum> range (e.g. >=24 -> >=24.11.0). The supported minimum is derived from package.json engines.node (no hardcoded per-major floors). Docs updated in migrate-rules.md and the migrate RFC. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
In the existing-Vite+ upgrade path the baseUrl, Prettier, node-version-file, and below-range Node confirms were shown while an execution-phase progress spinner (e.g. "Configuring package manager", "Migrating ESLint") was still running, so the spinner animated beneath the prompt. Each confirm now clears the spinner first, and the upgrade-path upgradeUnsupportedNodeVersions call passes clearMigrationProgress like the fresh path; the next progress update restarts it. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
…eractive - Add "unparseable" to .typos.toml (a valid variant of "unparsable" used in the migrate Node-pin docs/comments) so the typos check passes. - The upgrade-path spinner-clear before the baseUrl / Prettier / node-version confirms now runs only in interactive mode. Running it unconditionally added a spinner line to `vp migrate --no-interactive` output, which diffed several migration-* snaps; non-interactive output is now byte-identical to before while the interactive spinner-over-prompt fix is preserved. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
The existing-Vite+ upgrade path now injects a direct `vite: catalog:` for pnpm projects that depend on vite-plus (reconcileVitePlusBootstrapPackage), so the migrated manifests gain a `"vite": "catalog:"` entry. Regenerate the affected migration-eslint-rerun*, migration-prettier-rerun, migration-upgrade-*, and migration-vite-plus-in-dependencies-pnpm snaps to match; this also clears the CLI E2E (musl) snapshot-diff failure, which has the same cause. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
…ojects The bun#8406 workaround (a direct `vite` devDep so bun's pre-override peer walk resolves vitest's `vite` peer) hardcoded the concrete core alias, leaving `vite: npm:@voidzero-dev/vite-plus-core@<v>` while `vite-plus`, the override, and the pnpm/Yarn paths use `catalog:`. #8406 only requires `vite` to be a DIRECT dependency; a `catalog:` edge satisfies it too because catalog references resolve during the dependency-graph build (unlike overrides) -- verified on bun 1.3.11. Route both bun sites (rewriteStandaloneProject, reconcileVitePlusBootstrapPackage) through getCatalogDependencySpec so catalog-capable bun gets `catalog:` and non-catalog bun keeps the concrete alias. Adds the migration-upgrade-bun-catalog snap fixture for coverage. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
…the standalone path Pass the hoisted `supportCatalog` (matching the parameter name and the reconcileVitePlusBootstrapPackage caller) instead of `usePnpmWorkspaceYaml`. They are equivalent because ensureDirectViteForPnpm no-ops for non-pnpm, and this removes the comment that existed only to justify the usePnpmWorkspaceYaml form. Claude-Session: https://claude.ai/code/session_01DQhS6o1fyQd1yjiee6W8jR
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RFC:
rfcs/migrate-existing-projects.mdProblem
Running
vp migrateon an existing v0.1.x Vite+ project did not upgrade cleanly: it delegated to the stale local CLI, leftpnpm-workspace.yamloverrides pinningvite/vitestto old versions, and skewed coverage providers. The v0.2.1 release notes currently tell users not to runvp migrateyet.What this does (verified)
vite-plusis older than the globalvp, run migrate from the global CLI.vite-plus/vite->core spec so the lockfile moves off 0.1.x."pnpm": {}misrouting that left stalepnpm-workspace.yamloverrides.vitestby usage: removed in the common case (vite-plus provides it transitively), kept + ecosystem-aligned when the project uses it directly or via a range-peer integration.@vitest/*ecosystem (coverage-v8/-istanbul, ui, web-worker) to the bundled version; exclude@vitest/eslint-plugin.Node.js version upgrade
A project pinning a Node version below the Vite+ supported range (
package.json#engines.node, currently^20.19.0 || ^22.18.0 || >=24.11.0) makes package managers skip the native binding's optional dependency ("Cannot find native binding"). Migration now reads the effective Node pin (.node-version->devEngines.runtime->engines.node, reusing the Rust runtime resolver, with.nvmrc/Volta converted to.node-versionfirst) and rewrites an exact ormajor.minorpin below the range to the concrete latest release of that major (24.3.0/24.2->24.18.0). A bare major or an open range that still resolves to a supported release is left unchanged. Interactive migration confirms the upgrade (default yes);--no-interactiveapplies it directly.vp migrateon a fresh project pinning.node-version= 24.3.0 (below the range).node-versionis rewritten24.3.0->24.18.0. The confirm prompt pauses the migration progress spinner so it does not animate beneath the prompt.Known gaps (draft, follow-ups)
apps/dashboard) is left without@vitest/browser-playwrightand a directvitest, so browser tests break. The fresh-migration path handles this; the upgrade path must too.vitestin the package that needs it instead of the shared root catalog.vitestpin into removal for official-@vitest/*-only projects.migration-*snap suite and do the docs /npm deprecaterollout, then drop the "do not runvp migrate" disclaimer.Manual pkg.pr.new migration testing
Use the repository helper to install an isolated pkg.pr.new global CLI and run the PR version of
vp migrateagainst any local project:The first argument accepts either a PR number or commit SHA. The helper keeps the normal
~/.vite-plusinstallation untouched, forces migration through the installed global preview CLI even when the project has a same-version local CLI, pinsvite-plusandvite/core to the matching pkg.pr.new URLs, refuses dirty Git worktrees by default, and forwards additional options such as--no-interactivetovp migrate.