test: install local vite-plus builds through a local npm registry#2021
Merged
Conversation
…ures Install fixtures no longer pin VP_VERSION to a published release. The snap harness packs the checkout's vite-plus and @voidzero-dev/vite-plus-core once per run (localVitePlusPackages in steps.json), and mock-npm-registry.mjs serves the tarballs as single-version packuments (integrity over the exact bytes served, old time so minimum-release-age gates never quarantine them), proxying everything else upstream. Installs therefore resolve the checkout's own version even when it is not published yet, and release CI exercises the actual to-be-released packages through vp create / vp migrate. Wrapper fixes found while validating against an unpublished version: - pnpm 11 ignores npm_config_registry / NPM_CONFIG_REGISTRY, so the wrapper also sets PNPM_CONFIG_REGISTRY (pnpm was silently resolving from the real registry before) - Yarn Berry persists packuments with dead ephemeral-port tarball URLs and bun's install cache trusts name@version without refetching, so both get throwaway caches per invocation - the proxy reuses upstream connections, honors the user's ~/.npmrc registry (mirror-friendly locally, npmjs on CI), and forces identity encoding for tarballs only (mirror CDNs gzip them, which bun cannot extract) - wrapped install commands get a 120s timeout for cold-cache runs Closes #2018
✅ Deploy Preview for viteplus-preview canceled.
|
…ting Move the snap-test mock registry to packages/tools/src/local-npm-registry.mjs and make it a shared tool with three modes: wrap a command (snap fixtures via $SNAP_LOCAL_REGISTRY), --pack to self-pack the checkout from any project directory, and --serve to keep a server running (first stdout line is machine-readable JSON, followed by copy-paste env exports). Ecosystem e2e now installs the local build through the registry instead of file: specs: patch-project.ts starts one detached server for the whole job (env exported via GITHUB_ENV for later steps) and runs vp migrate/vp install through it with a real semver VP_VERSION read from the packed tgz. This removes the manual post-migrate package.json rewrite (migrate pins the version itself, catalog paths included), the bun vite-7.99.0 alias tgz (bun installs the standard npm:@voidzero-dev/vite-plus-core alias through a registry), and dify's file:-crash tolerance. verify-install.ts asserts the exact registry spec, accepting catalog references. For local development, vp migrate / vp create logic can be verified right after a build (about 16s) instead of publishing to pkg.pr.new and going through the registry bridge: node <repo>/packages/tools/src/local-npm-registry.mjs --pack -- vp migrate --no-interactive Documented in CONTRIBUTING.md, with a pnpm local-registry root script. Verified: bun-vite-template end-to-end (clone, migrate, bun install, verify-install) resolves everything through the local server with the installed vite-plus integrity differing from the published tarball; all 21 touched snap fixtures regenerate byte-identical; migrate/create/serve dev flows pass against scratch projects.
fengmk2
changed the title
…nance Convert the registry script to erasable-syntax TypeScript so it typechecks with the rest of packages/tools while still running directly with bare node (the repo's Node floor strips types natively), from any project directory and with no loader wiring. The tool bin gains a local-npm-registry subcommand, and the .d.mts stub for the untyped module import is gone. Add cross-platform --ps / --kill maintenance modes (ps on Unix, PowerShell Get-CimInstance on Windows, process.kill for termination): --ps lists registry processes left behind by interrupted runs, --kill stops them and removes their leftover temp caches. A process qualifies only when node is the executing binary of the script, so shells whose command string merely mentions it stay out of the kill list. Exposed as pnpm local-registry:ps and pnpm local-registry:kill.
The dify e2e job exposed a gap in the single-version packuments: ecosystem projects that already reference a PUBLISHED vite-plus version in their committed lockfile could not verify those entries against the replaced metadata (pnpm's time-based resolution policy failed with ERR_PNPM_TRUST_DOWNGRADE: Missing time for version 0.2.1). Serve local packages as an overlay on the real upstream packument instead, like the production registry bridge: upstream versions, times, and dist-tags stay visible, the local version is injected (winning over a published version with the same number so local builds always take precedence), and latest points at it. Falls back to the local-only packument when upstream is unreachable or the package has never been published.
The gate env (any spelling, even 0) combined with dify's resolutionMode: time-based activates pnpm's resolution-policy engine, which vp's bundled pnpm cannot handle (ERR_PNPM_RESOLUTION_POLICY_VIOLATIONS_UNHANDLED, no handleResolutionPolicyViolations callback wired). This is the same crash the old flow tolerated by swallowing dify's whole migrate failure; with the gate env excluded (dify's minimumReleaseAge key is already stripped by the workspace patch) the policy stays inactive and the migrate auto-install can actually succeed. The packument-merge fix from the previous commit already got dify past lockfile verification and the ESLint migration.
- extract the shared pack preflight+invocation into packages/tools/src/pack-local-vite-plus.ts, used by both the snap harness and local-npm-registry.ts --pack (was two hand-synced copies) - localVitePlusPackages fixtures get a 120s default command timeout in the harness instead of a pasted "timeout": 120000 on every wrapped command; steps.json env is optional now and empty env blocks are gone - drop the dead SNAP_CASES_DIR env (its last consumer left with .shared/) - serve packuments without a parse/stringify round trip and read local tarballs asynchronously so large responses do not stall in-flight proxied requests - tool local-npm-registry spawns the script by path instead of importing it under a spliced argv, so tool-launched servers match --ps/--kill - key the ecosystem release-age gate exception on resolutionMode: time-based in the project's workspace yaml instead of the dify project name - derive the expected e2e version from the packed tgz (vitePlusTgzVersion in ecosystem-ci/paths.ts) for both patch-project and verify-install, dropping the unused VP_EXPECTED_VERSION knob and the hardcoded 0.0.0 - document why the registry's upstream resolution deliberately ignores registry env vars
Member
Author
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d0cbcb51f8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- forward the original request method and body upstream so npm's POST endpoints (audit bulk advisories) work through the proxy; redirects are only followed for body-less methods since the body streams into the first request - resolve the upstream registry from the project .npmrc in cwd before the user ~/.npmrc, so projects on a custom registry keep resolving from it - remove the --pack temp directory in the normal cleanup paths (wrapper exit and --serve shutdown) instead of leaving it for --kill - document the deliberate limitations: registry env vars are ignored as upstream sources (stale exports from a previous --serve would become the upstream), and HTTP(S)_PROXY tunneling plus authenticated upstreams are out of scope for the environments this tool serves
Contributor
|
✅ Staging deployment successful! Preview: https://viteplus-staging.void.app/ |
Member
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. Can't wait for the next one! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
The alpha to beta announcement link change in Hero.vue was swept into 2d807d5 from the working tree by accident and is not part of this PR.
Restore docs/.vitepress/config.mts, Hero.vue, and docs/guide/troubleshooting.md to the branch merge-base so this PR carries no docs changes (the earlier Hero.vue revert targeted main, which had moved ahead of the merge-base).
A fresh pack per run keeps the served tarballs in sync with the current checkout build (a fixed reused directory would serve stale tarballs after a rebuild without an invalidation scheme), inherits the run's exit cleanup, and isolates concurrent snap-test processes. The localVitePlusPackages flag stays regardless of the directory choice: it gates the pack step and its build prerequisites to the fixtures that install local packages, and raises their default command timeout.
Migrate test-vp-create.yml off the file: override flow: the test jobs start a detached local registry serving the packed 0.0.0 build (env exported via GITHUB_ENV for all later steps), VP_VERSION becomes the plain semver, and the vite override uses the standard npm:@voidzero-dev/vite-plus-core alias for every package manager. The bun-only vite-7.99.0 alias tgz existed solely because bun's strict peer check rejects file: override targets; through a registry bun installs the standard alias (proven by the ecosystem e2e and snap fixtures), so the repack-vite-tgz tool loses its last consumer and is removed along with the tools package's nanotar dependency. This was the last test surface installing vite-plus via file: specs; snap fixtures, ecosystem e2e, and local dev iteration already go through packages/tools/src/local-npm-registry.ts.
With registry-resolved semver specs Yarn Berry hoists the workspace deps like a real install (the old file: overrides forced per-package node_modules copies at install time), so packages/utils/node_modules is born during run 1 and the directory fingerprint misses on run 2, same as npm (#1638). Give yarn the same single warm-up run before asserting the 100% cache hit.
- fail fast when the workflow's local registry server dies during startup (liveness check in the wait loop) instead of spinning until the job timeout, and read the handshake once with a simpler JSON one-liner - drop the step-level VP_OVERRIDE_PACKAGES from test-vp-create.yml: with VP_VERSION=0.0.0 the product default override map already pins the vite alias and the bundled vitest, and stays correct across vitest bumps without editing the workflow (fresh created projects have no committed lockfile, so the ecosystem-ci coverage-provider pins do not apply here) - dedupe the proxy's conditional header copying into copyHeaders - reword a migrator comment that still described the removed file: tgz override mode
Member
Author
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: da3ec89782
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
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: |
Contributor
Registry bridge build (
|
| Package | Version |
|---|---|
vite-plus |
0.0.0-commit.da3ec897825362d7e93de282ae7ebd0b895f7a28 |
@voidzero-dev/vite-plus-core |
0.0.0-commit.da3ec897825362d7e93de282ae7ebd0b895f7a28 |
Install the Vite+ CLI built from this commit, then migrate a project:
# macOS / Linux
curl -fsSL https://vite.plus | VP_PR_VERSION=2021 bash# Windows (PowerShell)
$env:VP_PR_VERSION="2021"; irm https://vite.plus/ps1 | iexAfter installing, upgrade the current project's vite-plus to this test build with:
vp migrateOr 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.da3ec897825362d7e93de282ae7ebd0b895f7a28",
"vite": "npm:@voidzero-dev/vite-plus-core@0.0.0-commit.da3ec897825362d7e93de282ae7ebd0b895f7a28"
}
}
Contributor
🐳 Docker preview imageBuilt from this PR's pkg.pr.new build:
# remove any stale local copy from a previous run, then pull fresh
docker rmi ghcr.io/voidzero-dev/vite-plus:pr-2021 2>/dev/null; docker pull ghcr.io/voidzero-dev/vite-plus:pr-2021Quick check: docker run --rm ghcr.io/voidzero-dev/vite-plus:pr-2021 vp --versionSee docs/guide/docker.md for usage. |
wan9chi
approved these changes
Jul 3, 2026
Member
Author
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 554df036f1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
In a proxied environment (HTTP_PROXY/HTTPS_PROXY without a loopback no-proxy entry) package managers would send the 127.0.0.1 registry requests through the proxy and never reach the local server. Extend the no-proxy list (NO_PROXY/no_proxy and npm's noproxy spellings, merged with any existing value) in the registry env so loopback traffic always goes direct.
Member
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
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
2 participants
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.
Serve the locally packed
vite-plus/@voidzero-dev/vite-plus-corethrough a local npm registry (packages/tools/src/local-npm-registry.ts), so tests and local development install the checkout's own build via the standard registry interface instead of published-version pins orfile:specs.localVitePlusPackagesinsteps.json) and wraps commands withnode $SNAP_LOCAL_REGISTRY -- vp .... Removes theVP_VERSION=0.2.1pins from test(snap): pin VP_VERSION to a published version in install fixtures #2017, so release branches pass before the version is published.Test vp create: one registry server per job (env viaGITHUB_ENV), real semverVP_VERSION, standardnpm:@voidzero-dev/vite-plus-corealias for every package manager. Removes thefile:overrides, the post-migrate package.json rewrite, the bunvite-7.99.0alias tgz, and therepack-vite-tgztool.node <repo>/packages/tools/src/local-npm-registry.ts --pack -- vp migrate --no-interactiveverifies migrate/create logic right after a build (about 16s instead of the 30 minute pkg.pr.new + registry-bridge round-trip).--servekeeps a reusable server;pnpm local-registry:ps/:killmanage leftovers. See CONTRIBUTING.md.Local packages are served as an overlay on the upstream packument (local version wins, upstream versions and
timestay visible for lockfile verification), with integrity computed over the exact bytes served and an old publish time so minimum-release-age gates pass. Everything else proxies upstream. All snap fixtures regenerate byte-identical, and the full CI matrix (snap shards, ecosystem projects including dify and bun, 16vp createjobs) is green on this flow.Closes #2018