Repository navigation
Conversation
Contributor
|
✅ Staging deployment successful! Preview: https://viteplus-staging.void.app/ |
fengmk2
added
the
preview-build
Contributor
Preview binary sizes (
|
| Binary | Latest release | Preview | Change |
|---|---|---|---|
vp (macOS ARM64) |
5.42 MiB | 5.42 MiB | 0 B (0.00%) |
| NAPI (macOS ARM64) | 43.01 MiB | 43.01 MiB | 0 B (0.00%) |
vp (macOS x64) |
6.90 MiB | 6.90 MiB | 0 B (0.00%) |
| NAPI (macOS x64) | 48.29 MiB | 48.29 MiB | +4.00 KiB (+0.01%) |
vp (Linux ARM64 GNU) |
6.88 MiB | 6.88 MiB | 0 B (0.00%) |
| NAPI (Linux ARM64 GNU) | 32.26 MiB | 32.26 MiB | 0 B (0.00%) |
vp (Linux ARM64 musl) |
6.95 MiB | 6.95 MiB | +128 B (+0.00%) |
| NAPI (Linux ARM64 musl) | 31.48 MiB | 31.48 MiB | +768 B (+0.00%) |
vp (Linux x64 GNU) |
8.31 MiB | 8.31 MiB | 0 B (0.00%) |
| NAPI (Linux x64 GNU) | 36.19 MiB | 36.19 MiB | +4.00 KiB (+0.01%) |
vp (Linux x64 musl) |
8.38 MiB | 8.38 MiB | 0 B (0.00%) |
| NAPI (Linux x64 musl) | 35.39 MiB | 35.40 MiB | +640 B (+0.00%) |
vp (Windows x64) |
6.16 MiB | 6.16 MiB | 0 B (0.00%) |
| NAPI (Windows x64) | 32.02 MiB | 32.02 MiB | +1.00 KiB (+0.00%) |
| Trampoline (Windows x64) | 13.00 KiB | 13.00 KiB | 0 B (0.00%) |
| Installer (Windows x64) | 4.67 MiB | 4.67 MiB | +512 B (+0.01%) |
vp (Windows ARM64) |
5.40 MiB | 5.40 MiB | +512 B (+0.01%) |
| NAPI (Windows ARM64) | 28.31 MiB | 28.31 MiB | +1.50 KiB (+0.01%) |
| Trampoline (Windows ARM64) | 13.00 KiB | 13.00 KiB | 0 B (0.00%) |
| Installer (Windows ARM64) | 3.84 MiB | 3.84 MiB | 0 B (0.00%) |
gzip -9 sizes
| Binary | Latest release | Preview | Change |
|---|---|---|---|
vp (macOS ARM64) |
3.24 MiB | 3.24 MiB | -88 B (-0.00%) |
| NAPI (macOS ARM64) | 18.68 MiB | 18.68 MiB | +1.65 KiB (+0.01%) |
vp (macOS x64) |
3.42 MiB | 3.42 MiB | -145 B (-0.00%) |
| NAPI (macOS x64) | 19.91 MiB | 19.91 MiB | +325 B (+0.00%) |
vp (Linux ARM64 GNU) |
3.73 MiB | 3.73 MiB | +412 B (+0.01%) |
| NAPI (Linux ARM64 GNU) | 13.74 MiB | 13.74 MiB | -1.94 KiB (-0.01%) |
vp (Linux ARM64 musl) |
3.75 MiB | 3.75 MiB | -276 B (-0.01%) |
| NAPI (Linux ARM64 musl) | 13.44 MiB | 13.44 MiB | -2.61 KiB (-0.02%) |
vp (Linux x64 GNU) |
3.80 MiB | 3.80 MiB | -4 B (-0.00%) |
| NAPI (Linux x64 GNU) | 14.44 MiB | 14.44 MiB | +369 B (+0.00%) |
vp (Linux x64 musl) |
3.82 MiB | 3.82 MiB | +262 B (+0.01%) |
| NAPI (Linux x64 musl) | 14.11 MiB | 14.11 MiB | +607 B (+0.00%) |
vp (Windows x64) |
2.85 MiB | 2.85 MiB | +175 B (+0.01%) |
| NAPI (Windows x64) | 13.11 MiB | 13.11 MiB | +720 B (+0.01%) |
| Trampoline (Windows x64) | 7.14 KiB | 7.14 KiB | +3 B (+0.04%) |
| Installer (Windows x64) | 2.24 MiB | 2.24 MiB | +16 B (+0.00%) |
vp (Windows ARM64) |
2.72 MiB | 2.72 MiB | -1.19 KiB (-0.04%) |
| NAPI (Windows ARM64) | 12.45 MiB | 12.45 MiB | +68 B (+0.00%) |
| Trampoline (Windows ARM64) | 6.92 KiB | 6.93 KiB | +2 B (+0.03%) |
| Installer (Windows ARM64) | 2.13 MiB | 2.13 MiB | -2 B (-0.00%) |
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.
Contributor
Registry bridge build (
|
| Package | Version |
|---|---|
vite-plus |
0.0.0-commit.b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef |
@voidzero-dev/vite-plus-core |
0.0.0-commit.b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef |
create-vite-plus |
0.0.0-commit.b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef |
Install the Vite+ CLI built from this commit, then migrate a project:
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/voidzero-dev/vite-plus/b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef/packages/cli/install.sh | VP_PR_VERSION=3317 VP_LEGACY_INSTALLER_URL=https://raw.githubusercontent.com/voidzero-dev/vite-plus/b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef/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/b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef/packages/cli/install-legacy.ps1"; irm https://raw.githubusercontent.com/voidzero-dev/vite-plus/b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef/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=b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef
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.b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef" --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.b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef # or: npm create vite-plus@0.0.0-commit.b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef$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.b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef # or: npm create vite-plus@0.0.0-commit.b74344f7f0d6b5a3ef1c2240fb033dff0e6042efpnpm 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.b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef",
"vite": "npm:@voidzero-dev/vite-plus-core@0.0.0-commit.b74344f7f0d6b5a3ef1c2240fb033dff0e6042ef"
}
}
Contributor
🐳 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. |
fengmk2
force-pushed
the
feat/core-version-alignment
branch
2 times, most recently
from
November 10, 2026 02:36
9316e2b to
7f41a5a
Compare
fengmk2
added
preview-build
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>
- Decide the stale pnpm peer-rule keys (`vitest` and `vite`) in one function, and check and remove them with shared helpers in the YAML writer, the package.json merge, and the satisfied check. - Define the core alias prefix once for the CLI and once for the scripts. - Read the bundled core manifest once in resolve-core, and compare the project's core with the core that the CLI resolves. - Read the core version only from VP_CORE_VERSION or the core manifest. - Reuse the core-version helpers in upgrade-deps, the download helper in the Homebrew updater, and readPackageJsonIfExists in the migrator. - Remove the unused VP_CORE_VERSION from the ecosystem CI migrate env. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Record the vite-plus version in the core manifest (`vitePlusVersion`). `core-version.ts prepare` writes it with the selected core version, and `check --release` fails unless the published core version is absent or belongs to the same vite-plus release. This covers two release PRs that select the same counter and a manual vite-plus bump. - Start the counter at `<vite>.vp.0` when the bundled Vite is a prerelease, and check the prerelease pairing only for a release. - Keep a user `allowedVersions.vite` range during migration. Migration only removes the managed `'*'` value and `allowAny: [vite]`. - Add a strict pnpm peer check case: a Vite 8 plugin installs through the core alias, and a Vite 7 plugin still fails. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Read the matching core alias with `npm view vite-plus@<version> dependencies.vite` when updating manually, and explain how to handle dependency bot updates that change only one of the two packages. - Run the core release check in the release check job too, so a stale or duplicate core version fails before the build. - Note that main can hold an unpublished core version, and link the CLI's stable-core rule to the version scheme module. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Follow the oxlint-tsgolint convention, which Vite+ bundles: the core patch is `vitePatch * 1000 + n`, with `n` from 0. Core 8.3.5000 is the first release on Vite 8.3.5, and local and CI builds use counter 999 (8.3.5999). The counter now allows 999 stable releases per Vite patch. The RFC also compares the `.vp.<k>` prerelease form with encoding the counter in the Vite prerelease number (`9.0.0-beta.3000`). The encoded form passes prerelease floors such as `^9.0.0-beta.5` by mistake, so the RFC keeps `.vp.<k>`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The local CI builds set the core version after the CLI build, so the CLI constant and its toolchain manifest kept the committed version and VP_CORE_VERSION had to correct the alias. Stamp the local core version before the build in test-vp-create and ecosystem CI instead. The CLI build, its toolchain manifest, and the packed `vite` alias then all read packages/core/package.json, and VP_CORE_VERSION is removed. The native build cache key does not include the core manifest. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
pnpm 9.x to 10.1.x apply the `vite@*` alias override to peer ranges, so every `vite` peer reads `vite@npm:@voidzero-dev/vite-plus-core@<version>` and fails against the installed core without the rule. Pass the pnpm version to the peer-rule helpers and keep the rule on those versions. - Add a strict pnpm peer check case in the layout that `vp migrate` writes, with the `vite@*` alias override. - Correct the docs: an incompatible plugin gets a peer warning on pnpm and Yarn. npm applies `overrides.vite` to peer edges, and Bun reports no peer problems. The overrides stay because they keep one core instance. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add a section with the user-visible effect: the version mapping, pnpm strict installs for compatible and incompatible plugins, the `pnpm-workspace.yaml` change that `vp migrate` makes, the npm `ERESOLVE` warnings from #2806, and a summary by package manager with the known limits on npm and Bun. 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>
fengmk2
force-pushed
the
feat/core-version-alignment
branch
from
November 10, 2026 17:46
c5befa2 to
2637958
Compare
This branch has not been deployed
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
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.
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.vite-plus<major>.<minor>.<patch * 1000 + n>8.3.7:8.3.7000,8.3.7001vite-plusprerelease, stable Vite<next stable core version>-vp.<k>8.3.7001-vp.0vite-plusprerelease, Vite prerelease<vite version>.vp.<k>9.0.0-beta.3.vp.0n = 9998.3.7999<vite version>.vp.9999.0.0-beta.3.vp.999The committed core version is now
8.3.7000(bundled Vite8.3.7). Core8.xsorts above every published1.xand0.xversion.Peer results against the alias, before and after:
vitepeer range1.5.18.3.7000^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 two remaining false results: a patch floor above the bundled patch inside the same minor (
>=8.3.8passes against8.3.7000), and an exact pin (8.3.7fails).vp toolchainOnly the core node changes. Before, it showed the
vite-plusversion (@voidzero-dev/vite-plus-core@1.5.1). 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 migrateno longer addsvitetopeerDependencyRules.allowAnyorallowedVersions. It removesallowAny: [vite]andallowedVersions.vite: '*', also when the user wrote them, deletes emptied maps, and printsRemoved \vite` from pnpm peerDependencyRules: the core version now matches the bundled Vite. A user range such asallowedVersions.vite: '7 || 8'stays. The rule also stays on pnpm before 10.2.0, which applies thevite@*alias override to peer ranges, and for preview and prerelease cores. Thevitest` entries do not change.vitepeer range excludes the bundled Vite now produces a peer warning. WithstrictPeerDependencies, the install fails. The docs recommend a rule for that plugin only:'vite-plugin-foo>vite:peer': '*'inoverrideson pnpm 12.17.0 and later, where pnpm deprecatespeerDependencyRules, or a scopedallowedVersionsentry on earlier pnpm.vitepeer range now accepts the core alias in thevite-plusdependency tree, which removes theERESOLVE overriding peer dependencywarnings in Support strict pnpm peer validation with the required Vite core alias #2806. A tagged alias such asnpm:@voidzero-dev/vite-plus-core@latestnow stays on the core, and in a project that declares onlyvite-plus, Vitest'svitepeer resolves to the CLI's core. npm appliesoverrides.viteto peer edges, so it does not report an incompatible plugin. Bun reports no peer problems.viteandvitestoverrides and resolutions keep one core and one Vitest instance on every package manager. The version scheme does not replace them.vitealias, not with the CLI version. In the repository layout (workspace:spec), it compares the project's core with the core that the CLI resolves.<core-version>for the alias. They read it withnpm view vite-plus@<version> dependencies.vitebefore an install, orvp toolchain vite-plus-coreafter one, and explain how to handle dependency bot updates that change only one of the two packages.Release pipeline
prepare_release.ymlrunspackages/tools/src/core-version.ts prepare. It selects the next unpublished core version from the registry, writes it and thevite-plusversion (vitePlusVersion) to the core manifest, and names both versions in the release PR.release.ymlrunscore-version.ts check --releasein the check job and again before publishing. The check fails when the registry already holds the core version for a differentvite-plusrelease, for example after two release PRs select the same counter, or after a manualvite-plusbump. It also rejects the local counter 999.release.ymlpublishes and waits for core at its own version, uses it in the release body and the Discord message, and checks the corelatestdist-tag after publish. The Homebrew updater reads the core version from the publishedvite-plusalias.reusable-release-build.ymlstamps core only for preview builds. The Rolldown binding guard now uses the CLI version, because the platform packages publish at the CLI version.test-vp-create.ymlandreusable-ecosystem-ci.ymlset the local core version (core-version.ts local: counter 999, never used by a release) before the build. The CLI constants, the toolchain manifest, and the packed alias all read it frompackages/core/package.json, which is the only source of the core version..github/scripts/upgrade-deps.tsresets the counter when the bundled Vite changes:n = 0on a stable Vite,<vite>.vp.0on a Vite prerelease. A unit test inpackages/corerequires the committed version to encodebundledVersions.vite.Not in this PR
vitestpeer rule. It is redundant, because thevitestoverride already sets the version that peer checks see.latestdist-tag. This behavior existed before this PR.vite-plusmajor release. The release policy decides this.🤖 Generated with Claude Code