Repository navigation
feat: align the core version with the bundled Vite version - #3317
Conversation
|
✅ Staging deployment successful! Preview: https://viteplus-staging.void.app/ |
Preview binary sizes (
|
| Binary | Latest release | Preview | Change |
|---|---|---|---|
vp (macOS ARM64) |
5.46 MiB | 5.46 MiB | +32 B (+0.00%) |
| NAPI (macOS ARM64) | 43.39 MiB | 43.40 MiB | +16.14 KiB (+0.04%) |
vp (macOS x64) |
6.92 MiB | 6.92 MiB | +4.03 KiB (+0.06%) |
| NAPI (macOS x64) | 48.76 MiB | 48.76 MiB | +8 B (+0.00%) |
vp (Linux ARM64 GNU) |
6.90 MiB | 6.91 MiB | +4.05 KiB (+0.06%) |
| NAPI (Linux ARM64 GNU) | 32.68 MiB | 32.66 MiB | -20.00 KiB (-0.06%) |
vp (Linux ARM64 musl) |
6.97 MiB | 6.98 MiB | +7.58 KiB (+0.11%) |
| NAPI (Linux ARM64 musl) | 31.89 MiB | 31.89 MiB | -2.75 KiB (-0.01%) |
vp (Linux x64 GNU) |
8.33 MiB | 8.35 MiB | +16.05 KiB (+0.19%) |
| NAPI (Linux x64 GNU) | 36.69 MiB | 36.70 MiB | +4.00 KiB (+0.01%) |
vp (Linux x64 musl) |
8.41 MiB | 8.42 MiB | +4.70 KiB (+0.05%) |
| NAPI (Linux x64 musl) | 35.90 MiB | 35.90 MiB | +1.13 KiB (+0.00%) |
vp (Windows x64) |
6.19 MiB | 6.20 MiB | +5.00 KiB (+0.08%) |
| NAPI (Windows x64) | 32.45 MiB | 32.45 MiB | +1.50 KiB (+0.00%) |
| Trampoline (Windows x64) | 13.00 KiB | 13.00 KiB | 0 B (0.00%) |
| Installer (Windows x64) | 4.69 MiB | 4.69 MiB | +4.00 KiB (+0.08%) |
vp (Windows ARM64) |
5.42 MiB | 5.42 MiB | +5.00 KiB (+0.09%) |
| NAPI (Windows ARM64) | 28.66 MiB | 28.66 MiB | +2.50 KiB (+0.01%) |
| Trampoline (Windows ARM64) | 13.00 KiB | 13.00 KiB | 0 B (0.00%) |
| Installer (Windows ARM64) | 3.86 MiB | 3.86 MiB | +4.00 KiB (+0.10%) |
gzip -9 sizes
| Binary | Latest release | Preview | Change |
|---|---|---|---|
vp (macOS ARM64) |
3.25 MiB | 3.25 MiB | +2.75 KiB (+0.08%) |
| NAPI (macOS ARM64) | 18.85 MiB | 18.85 MiB | +3.28 KiB (+0.02%) |
vp (macOS x64) |
3.43 MiB | 3.43 MiB | +4.69 KiB (+0.13%) |
| NAPI (macOS x64) | 20.12 MiB | 20.12 MiB | +3.50 KiB (+0.02%) |
vp (Linux ARM64 GNU) |
3.74 MiB | 3.75 MiB | +4.68 KiB (+0.12%) |
| NAPI (Linux ARM64 GNU) | 13.93 MiB | 13.93 MiB | -1.59 KiB (-0.01%) |
vp (Linux ARM64 musl) |
3.77 MiB | 3.77 MiB | +2.28 KiB (+0.06%) |
| NAPI (Linux ARM64 musl) | 13.64 MiB | 13.63 MiB | -1.82 KiB (-0.01%) |
vp (Linux x64 GNU) |
3.81 MiB | 3.82 MiB | +3.24 KiB (+0.08%) |
| NAPI (Linux x64 GNU) | 14.65 MiB | 14.65 MiB | +1.86 KiB (+0.01%) |
vp (Linux x64 musl) |
3.84 MiB | 3.84 MiB | +4.02 KiB (+0.10%) |
| NAPI (Linux x64 musl) | 14.33 MiB | 14.33 MiB | -3.30 KiB (-0.02%) |
vp (Windows x64) |
2.86 MiB | 2.87 MiB | +4.04 KiB (+0.14%) |
| NAPI (Windows x64) | 13.31 MiB | 13.31 MiB | -1.13 KiB (-0.01%) |
| Trampoline (Windows x64) | 7.14 KiB | 7.14 KiB | 0 B (0.00%) |
| Installer (Windows x64) | 2.25 MiB | 2.25 MiB | +1.87 KiB (+0.08%) |
vp (Windows ARM64) |
2.73 MiB | 2.73 MiB | +1.60 KiB (+0.06%) |
| NAPI (Windows ARM64) | 12.62 MiB | 12.62 MiB | -618 B (-0.00%) |
| Trampoline (Windows ARM64) | 6.93 KiB | 6.92 KiB | -2 B (-0.03%) |
| Installer (Windows ARM64) | 2.14 MiB | 2.14 MiB | +2.48 KiB (+0.11%) |
Raw sizes are uncompressed file sizes. gzip sizes recompress each binary at level 9; they are not package or download archive sizes.
The baseline uses published release files, including NAPI packages from npm at the same version. Build versions and toolchains can affect the difference.
Registry bridge build (
|
| Package | Version |
|---|---|
vite-plus |
0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1 |
@voidzero-dev/vite-plus-core |
0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1 |
create-vite-plus |
0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1 |
Install the Vite+ CLI built from this commit, then migrate a project:
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/voidzero-dev/vite-plus/9507271ad6a2ae552a8adc1d71914e47ad1aecc1/packages/cli/install.sh | VP_PR_VERSION=3317 VP_LEGACY_INSTALLER_URL=https://raw.githubusercontent.com/voidzero-dev/vite-plus/9507271ad6a2ae552a8adc1d71914e47ad1aecc1/packages/cli/install-legacy.sh bash# Windows (PowerShell)
$env:VP_PR_VERSION="3317"; $env:VP_LEGACY_INSTALLER_URL="https://raw.githubusercontent.com/voidzero-dev/vite-plus/9507271ad6a2ae552a8adc1d71914e47ad1aecc1/packages/cli/install-legacy.ps1"; irm https://raw.githubusercontent.com/voidzero-dev/vite-plus/9507271ad6a2ae552a8adc1d71914e47ad1aecc1/packages/cli/install.ps1 | iexOr install with Homebrew (macOS / glibc Linux):
These commands use the formula and binary from this published commit. Replace brew install with brew reinstall if the tap package is already installed.
If Homebrew Core’s vite-plus is installed, run brew uninstall vite-plus first. This keeps your user data; do not run vp implode to switch installations.
(
set -eu
export HOMEBREW_NO_AUTO_UPDATE=1
export HOMEBREW_VP_PR_VERSION=9507271ad6a2ae552a8adc1d71914e47ad1aecc1
brew tap voidzero-dev/vite-plus https://github.com/voidzero-dev/vite-plus
preview_tap="$(brew --repository voidzero-dev/vite-plus)"
git -C "$preview_tap" fetch --depth=1 https://github.com/voidzero-dev/vite-plus.git "$HOMEBREW_VP_PR_VERSION"
git -C "$preview_tap" switch --detach "$HOMEBREW_VP_PR_VERSION"
brew install voidzero-dev/vite-plus/vp
brew test voidzero-dev/vite-plus/vp
"$(brew --prefix)/bin/vp"
)The tap stays at the tested commit. Return it to main after testing:
git -C "$(brew --repository voidzero-dev/vite-plus)" switch mainOr download the standalone Windows installer built from this commit:
| Architecture | Installer |
|---|---|
| x64 | vp-setup-x86_64-pc-windows-msvc.exe |
| Arm64 | vp-setup-aarch64-pc-windows-msvc.exe |
GitHub requires you to sign in and downloads each installer as a ZIP artifact. Extract vp-setup.exe, then run it against this preview build:
.\vp-setup.exe --version "0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1" --registry "https://registry-bridge.viteplus.dev/"After installing, upgrade the current project's vite-plus to this test build with:
vp migrateOr create a new project from this commit without installing the CLI:
export npm_config_registry=https://registry-bridge.viteplus.dev/ pnpm_config_registry=https://registry-bridge.viteplus.dev/
pnpm create vite-plus@0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1 # or: npm create vite-plus@0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1$env:npm_config_registry="https://registry-bridge.viteplus.dev/"; $env:pnpm_config_registry="https://registry-bridge.viteplus.dev/"
pnpm create vite-plus@0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1 # or: npm create vite-plus@0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1pnpm 11+ reads pnpm_config_registry, npm and older pnpm read npm_config_registry. The new project pins this build, so keep the registry set for later installs, or configure it as below.
Or point your package manager at the bridge registry https://registry-bridge.viteplus.dev/:
| Package manager | Registry config |
|---|---|
| npm / pnpm / Bun | .npmrc: registry=https://registry-bridge.viteplus.dev/ |
| Yarn (v2+) | .yarnrc.yml: npmRegistryServer: "https://registry-bridge.viteplus.dev/" |
Then pin the build (vite aliases to vite-plus-core; pnpm can use a catalog, npm an overrides entry):
{
"devDependencies": {
"vite-plus": "0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1",
"vite": "npm:@voidzero-dev/vite-plus-core@0.0.0-commit.9507271ad6a2ae552a8adc1d71914e47ad1aecc1"
}
}
🐳 Docker preview imageBuilt from this PR's registry bridge build:
# remove any stale local copy from a previous run, then pull fresh
docker rmi ghcr.io/voidzero-dev/vite-plus:pr-3317 2>/dev/null; docker pull ghcr.io/voidzero-dev/vite-plus:pr-3317Quick check: docker run --rm ghcr.io/voidzero-dev/vite-plus:pr-3317 vp --versionSee docs/guide/docker.md for usage. |
9316e2b to
7f41a5a
Compare
2637958 to
ce92b4c
Compare
Propose a version scheme for @voidzero-dev/vite-plus-core that encodes the bundled Vite version: the core major and minor equal Vite's, and the core patch is `vitePatch * 100 + n`. Vite+ prereleases use a `vp.<k>` identifier. With this scheme, peer checks against the `vite` alias pass for compatible consumers and still fail for incompatible ones, so migration can drop the broad pnpm `vite` peer rule. Refs #2806, #3277 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Encode the bundled Vite version in the @voidzero-dev/vite-plus-core version, as rfcs/core-version-alignment.md describes. The core major and minor equal Vite's, and the patch is `vitePatch * 100 + n`. Core 8.3.500 bundles Vite 8.3.5. With the `vite` alias, package managers now check plugin peer ranges against the bundled Vite. - Add packages/tools/src/core-version.ts to encode, decode, select, and check core versions. Vite+ prereleases use a `vp.<k>` identifier, and local CI builds use the reserved counter 99. - Select the core version from the registry in prepare_release, publish core at its own version, and check its latest dist-tag after publish. - Bake the CLI version into the Rolldown binding guards, because the platform packages publish at the CLI version. - Resolve the expected core version from the CLI's `vite` alias, and map the core package to its own version in sync-versions. - Stop writing the pnpm `vite` peer rule for a stable core, remove an existing one, and keep it for preview and prerelease cores. - Reset the core version when upgrade-deps changes the bundled Vite. Refs #2806, #3277 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The repository CLI declares `vite: workspace:@voidzero-dev/vite-plus-core@*`, which has no exact version. The core check then compared only the package name, so a project core with a stale version passed and `vp dev` started. Fall back to the version of the core that the CLI resolves. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Remove the pnpm `vite` peer rule from migration snapshots, and record the summary line for projects whose rule migration removes. - npm now keeps a tagged core alias and resolves Vitest's `vite` peer to the CLI's core, because the core version satisfies that range. Replace the tagged-alias rejection case with a case that checks the shared core, and update the CLI-only layout check. - Read the core version from the core manifest or the CLI alias in the core identity fixtures, not from the vite-plus version. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Homebrew updater waited for @voidzero-dev/vite-plus-core at the CLI version. The core version now encodes the bundled Vite version, so that wait could never succeed. Read the core version from the `vite` alias of the published vite-plus manifest instead. The manual recovery command keeps its single version argument. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
pnpm 12.17.0 deprecates `peerDependencyRules` (pnpm/pnpm#17457). For a plugin whose `vite` peer range excludes the bundled Vite, the migrate rules now recommend the override `'vite-plugin-foo>vite:peer': '*'` on pnpm 12.17.0 and later, and the scoped `allowedVersions` entry on earlier pnpm. The RFC records the deprecation: migration still writes the setting for preview and prerelease cores, pnpm before 10.2.0, and the redundant `vitest` rule, which the planned follow-up removes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Keep only the `pnpm-workspace.yaml` diff that `vp migrate` produces and the cases that keep the rule. The npm and Bun limits stay in the Migration section. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Show the core versions that `nextCoreVersion` gives for `vite-plus` betas on the stable Vite 8.3.7: each beta appends `-vp.<k>` to the next stable core version, and the stable release then takes that base. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Show the core versions for three minor releases and one major release of vite-plus that all bundle Vite 8.3.7: only the release counter changes. Add a risk item: a vite-plus breaking change can be a core patch bump, so ranges on the core package are not supported. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Run `nextCoreVersion` over the two release sequences from the RFC: minor and major vite-plus releases on one Vite version, and betas on a stable Vite followed by the stable release. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Replace `stalePeerDependencyRuleKeys` and `managedPeerDependencyRuleKeys` with `pnpmPeerDependencyRuleKeys(usesVitest, pnpmVersion)`, and pass its result to the merge, the satisfied check, and the bootstrap writer. The pnpm version is now a required parameter, so a new caller cannot drop the `vite` rule on old pnpm by omission. - Compare the pnpm version with verkit `isLessThan` and a named constant. - Add `coreAliasVersion` for the CLI's core alias parsing, and use the alias prefix constant in ecosystem CI. - Read the published core manifests in `core-version.ts` with one packument fetch for both `prepare` and `check --release`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…rder - Count every version number that npm has used when selecting the core counter, including unpublished ones. npm never accepts an unpublished number again, but the packument keeps it only in `time`. - Queue release runs with `concurrency: release`. A second run that overlaps the first could check the same core version while npm still hides the first publish, pass, and pin its CLI to the first run's core. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…release `core-version.ts local` called `encodeCoreVersion(vite, 999)`, which rejects a Vite prerelease, so "Set local core version" failed in CI when the bundled Vite was a prerelease. Local builds now use `<vite>.vp.999` on a Vite prerelease. Counter 999 is reserved in both forms: releases never select it, and `check --release` rejects it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The create snapshots from #3197 use pnpm 10.4.1 to 10.6.1 and the latest pnpm. With a stable core on pnpm 10.2.0 and later, `vp create` no longer writes the `vite` peer rule. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
v1.6.0 shipped core 1.6.0 with the old scheme, so the first release with the encoded core version is the next one. Move the examples and the matching release-sequence tests one minor version forward. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…shed ones - `release.yml` also starts on changes to `packages/core/package.json`. When `check --release` rejects the core version after the merge, the PR from a new Prepare Release run changes only that file, and before this change its merge started no release. - `check --release` rejects a core version number that was unpublished. npm does not accept it again, and the publish script would take npm's rejection for an earlier upload of the same release. - Test `prepare` and `check --release` against a local mock registry. - The release-manager skill covers the recovery and a bundled Vite change merged into the release branch. - The RFC examples start after v1.6.0, and the RFC describes the packument read, patch ceilings, the local version scope, the checked `version` export, and the snapshot changes on a prerelease Vite. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#3436 upgraded the bundled Vite to 8.3.8 on main, so the committed core version moves from 8.3.7000 to 8.3.8000. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Keep every decision, rule, and risk, and remove repeated text: the alternatives that the scheme comparison already covers, the file-by-file tables, the experiment setup details, and the decisions from review. Merge the two release sequence examples into one table on the bundled Vite 8.3.8, and update the matching test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
9507271 to
66a296e
Compare
Remove the pnpm 12.17.0 deprecation, which is a pnpm change, and the npm warnings for preview builds and prereleases, which existed before or are in the Prereleases section. Move the registry failure behavior of `prepare` to its description. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The open question has an answer: the vite-plus release that first bundles a new Vite major is a major release, and so are its prereleases on a Vite major prerelease. Record the rule in the RFC and the release-manager skill, and remove the Open questions section. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
I wanna share a great "side effect" of this change: For npm & bun users, if they only install See for https://github.com/liang-demos/vite-plus-core-peer-resolution and more detail. It might be good to include it in the PR description or future tweets or so. |
Closes #2806. Part of the Q4 plan in #3277 ("Align the Core Version with Vite").
@voidzero-dev/vite-plus-corenow has a version that encodes the bundled Vite version. Projects aliasviteto the core package, and package managers compare the alias target's version with plugin peer ranges. With core1.x, everyvitepeer check failed, so pnpm projects needed broadpeerDependencyRulesexceptions, and npm printedERESOLVE overriding peer dependencywarnings with no per-package fix. With this change, compatible plugins pass the check, and incompatible plugins still fail it on pnpm and Yarn.The design is in
rfcs/core-version-alignment.md.Version scheme
The core major and minor equal the Vite major and minor. The core patch is
vitePatch * 1000 + n, wherencounts stable Vite+ releases on one Vite version, from 0.vite-pluskeeps its own1.xline. A Vite major upgrade is also avite-plusmajor release.vite-plus<major>.<minor>.<patch * 1000 + n>8.3.8:8.3.8000,8.3.8001vite-plusprerelease, stable Vite<next stable core version>-vp.<k>8.3.8001-vp.0vite-plusprerelease, Vite prerelease<vite version>.vp.<k>9.0.0-beta.3.vp.0n = 9998.3.8999<vite version>.vp.9999.0.0-beta.3.vp.999The committed core version is now
8.3.8000(bundled Vite8.3.8). Core8.xsorts above every published1.xand0.xversion.Peer results against the alias, before and after:
vitepeer range1.6.08.3.8000^8.0.0(@vitejs/plugin-react)^6.4.0 || ^7.0.0 || ^8.0.0(Vitest 5)>=8.3.2^7.0.0The scheme has three remaining false results: a patch floor above the bundled patch inside the same minor (
>=8.3.9passes against8.3.8000), a patch ceiling inside the same minor (<8.3.10fails), and an exact pin (8.3.8fails).vp toolchainOnly the core node changes. Before, it showed the
vite-plusversion (@voidzero-dev/vite-plus-core@1.6.0). After, it shows the encoded version, and the line under it shows the Vite version that it encodes:vp toolchain vite-plus-coreprints only the core line. The manual upgrade docs use it to read the alias version.Behavior changes
vp migrateremovesvitefrompeerDependencyRulesand prints a line that says so. A user range such asallowedVersions.vite: '7 || 8'stays. The rule stays on pnpm before 10.2.0 and for preview and prerelease cores.vitepeer range excludes the bundled Vite produces a peer warning again. The migration rules document a rule for that plugin only.ERESOLVE overriding peer dependencywarnings from Support strict pnpm peer validation with the required Vite core alias #2806 are gone. npm still does not report an incompatible plugin, becauseoverrides.vitealso applies to peer edges.vitealias, not with the CLI version.vite-plus, with novitealias or overrides, Vitest'svitepeer now resolves to the CLI's core. Before, npm and Bun installed upstream Vite and Rolldown as a second copy for Vitest, so Vitest and the CLI loaded different Vite instances.node_modulesis about 20.5 MiB smaller on macOS arm64, mostly from the Rolldown native binding (17.34 MiB):1.6.0)pnpm and Yarn already shared the CLI's core, so their size does not change. They no longer print a peer warning.
🤖 Generated with Claude Code