docs: update preview-build content for the registry bridge publish

Preview builds now publish only to the registry bridge, so update the content
that still described pkg.pr.new as the publish destination: MAINTENANCE.md's
preview section (the direct pkg.pr.new URL install no longer exists for new
builds), the upgrade guide, Dockerfile comments, install script and code
comments, and the migrate test harness (its manual-register fallback advice is
replaced by re-labeling the PR, since a bare registered ref has no artifacts
to fall back to anymore).

Kept as-is: the pkg.pr.new label and file/flag/env names (muscle memory and
API stability), pkg.pr.new-style URL/header descriptors (accurate style
descriptions), legacy pkg.pr.new-URL migration tests and fixtures (the
migrator still rewrites those specs from existing projects), and historical
RFCs.

Author: fengmk2

.claude/skills/test-pkg-pr-new-migrate/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: test-pkg-pr-new-migrate
-description: Verify a pkg.pr.new build of vite-plus against a real project before release — run `vp migrate` from the pkg.pr.new commit against a local project, deps resolved through the registry bridge. Use when asked to verify/e2e-test a pkg.pr.new build against a project, "test PR #<N> on <project>", or check a prerelease against a repo.
+description: Verify a preview (registry bridge) build of vite-plus against a real project before release — run `vp migrate` from the preview commit against a local project, deps resolved through the registry bridge. Use when asked to verify/e2e-test a preview or pkg-pr-new build against a project, "test PR #<N> on <project>", or check a prerelease against a repo.
 allowed-tools: Bash, Read
 ---
 
-# Verify a pkg.pr.new build against one project
+# Verify a preview build against one project
 
 Installs an isolated global `vp` built from a registry bridge commit build and runs `vp migrate` on a specified local project. The global CLI and the migrated project both pin `vite-plus`/`vite` to the clearly-defined `0.0.0-commit.<sha>` build. `vp migrate` itself writes the bridge registry into the project's `.npmrc` (or `.yarnrc.yml` for Yarn Berry) so the deps resolve, during this run and in the project's own CI; this script only force-stages that file past `.gitignore`.
 
@@ -16,7 +16,7 @@ Required inputs: a `<PR-or-SHA>` (the build to verify) and a `<project-path>`. I
 .github/scripts/test-pkg-pr-new-migrate.sh 1891 /path/to/npmx.dev --no-interactive
 ```
 
-- First arg is a PR number or commit SHA; the script resolves the immutable commit via the bridge `x-commit-key` header and verifies the bridge serves it (the pkg.pr.new publish workflow registers each commit).
+- First arg is a PR number or commit SHA; the script resolves the immutable commit via the bridge `x-commit-key` header and verifies the bridge serves it (the preview publish workflow, triggered by the `pkg.pr.new` label, registers each commit).
 - Never touches `~/.vite-plus`; clears only the workspace ROOT lockfile + `node_modules` before migrating; refuses a dirty worktree unless `ALLOW_DIRTY=1`; prints the project's `git status`/`diff` at the end — inspect that to confirm the migration result.
 
 **The build under test must include the "migrate writes the bridge registry" feature** (this session's work / current branch head onward). The harness no longer writes the registry itself — it relies on `vp migrate` doing it. Testing an older build with this harness would leave the project with no bridge registry, so its deps resolve from npmjs (`ERR_PNPM_NO_MATCHING_VERSION` on the `0.0.0-commit.<sha>` version). Always verify a fresh build of the branch, not a stale published commit.

.github/scripts/test-pkg-pr-new-migrate.sh

@@ -108,16 +108,14 @@ resolved_ref="$available_commit"
 commit_version="0.0.0-commit.$resolved_ref"
 vite_core_spec="npm:@voidzero-dev/vite-plus-core@$commit_version"
 
-# The bridge only serves commit builds it has been told about (registered by the
-# pkg.pr.new publish workflow). Fail early with an actionable message instead of
-# letting the project install hit an opaque registry miss.
+# The bridge only serves commit builds published by the preview publish
+# workflow (triggered by the `pkg.pr.new` label). Fail early with an actionable
+# message instead of letting the project install hit an opaque registry miss.
 if ! curl -fsS "${bridge_registry}@voidzero-dev/vite-plus-core" 2>/dev/null |
   grep -q "0.0.0-commit.$resolved_ref"; then
   echo "error: the registry bridge has no build for commit $resolved_ref" >&2
-  echo "Ensure the pkg.pr.new publish workflow registered it, or register it manually:" >&2
-  echo "  curl -fsS -X POST -H \"authorization: Bearer \$PKG_PR_BRIDGE_ADMIN_TOKEN\" \\" >&2
-  echo "    -H 'content-type: application/json' -d '{\"ref\":\"commit.$resolved_ref\"}' \\" >&2
-  echo "    ${bridge_registry}-/refs" >&2
+  echo "Publish it by re-adding the pkg.pr.new label to the PR (the preview publish" >&2
+  echo "workflow packs, uploads, and registers each labeled commit)." >&2
   exit 1
 fi
 

.github/workflows/reusable-release-build.yml

@@ -64,7 +64,7 @@ jobs:
           set -euo pipefail
           # Stamp ${VERSION} as the [package] version so CARGO_PKG_VERSION matches
           # the version that gets published/installed (the release version, or
-          # 0.0.0-commit.<sha> for pkg.pr.new). Anchored to the line-start
+          # 0.0.0-commit.<sha> for preview builds). Anchored to the line-start
           # `version = "..."` so crate dependency versions are never touched.
           for f in crates/vite_global_cli/Cargo.toml packages/cli/binding/Cargo.toml; do
             node -e 'const fs=require("fs"),f=process.argv[1];fs.writeFileSync(f,fs.readFileSync(f,"utf8").replace(/^version = "[^"]*"/m,`version = "${process.env.VERSION}"`))' "$f"

MAINTENANCE.md

@@ -2,12 +2,21 @@
 
 ## Publishing Preview Packages
 
-Publish to https://pkg.pr.new/~/voidzero-dev/vite-plus
+Add the `pkg.pr.new` label to the PR (the label name predates the registry
+bridge). Each labeled commit is published to the
+[registry bridge](https://registry-bridge.viteplus.dev/-/refs) as the npm
+version `0.0.0-commit.<sha>`; the PR gets a sticky comment with the exact
+version and install steps.
 
-Add the `pkg.pr.new` label to the PR.
+Install a preview build with the install script (PR number or commit sha):
 
-Use the commit sha, e.g.:
+```sh
+curl -fsSL https://vite.plus | VP_PR_VERSION=1569 bash
+```
+
+Or pin it in a project through the bridge registry (`.npmrc`:
+`registry=https://registry-bridge.viteplus.dev/`):
 
 ```sh
-pnpm add https://pkg.pr.new/voidzero-dev/vite-plus@sha
+pnpm add vite-plus@0.0.0-commit.<sha>
 ```

docker/Dockerfile

@@ -20,7 +20,7 @@ LABEL org.opencontainers.image.source="https://github.com/voidzero-dev/vite-plus
 #   docker build --build-arg VP_VERSION=1.4.2 .
 ARG VP_VERSION=latest
 
-# Optional: build a preview image from a pkg.pr.new build instead of npm.
+# Optional: build a preview image from a registry bridge build instead of npm.
 # Set to a PR number or commit SHA; when set it overrides VP_VERSION.
 #   docker build --build-arg VP_PR_VERSION=1569 .
 ARG VP_PR_VERSION=
@@ -50,7 +50,7 @@ ENV VP_HOME=/home/vp/.vite-plus \
     PATH=/home/vp/.vite-plus/bin:$PATH
 
 # Install the vp global CLI. The installer downloads the platform package from
-# npm (or from pkg.pr.new when VP_PR_VERSION is set). Node.js itself is
+# npm (or from the registry bridge when VP_PR_VERSION is set). Node.js itself is
 # provisioned per-project by vp at build time, honoring `.node-version` /
 # `engines.node` / `devEngines.runtime`.
 #

docs/guide/upgrade.md

@@ -62,7 +62,7 @@ Then set the `vitest` override to that exact version, or rerun `vp migrate` to u
 
 Some Vite+ pull requests publish temporary packages for testing before an npm release. Treat these as nightly or bleeding-edge builds: they are useful when you want to verify a specific fix, test a fresh upstream dependency bump, or confirm a change before the next release. For day-to-day work, prefer the published `latest` release.
 
-Each commit on an eligible pull request is published to [pkg.pr.new](https://pkg.pr.new) and registered with the [registry bridge](https://registry-bridge.viteplus.dev/). The bridge serves these builds as ordinary npm versions of the form `0.0.0-commit.<sha>` and proxies every other package to the npm registry. That means you install a preview with normal version specs instead of mutable URLs, and the same versions resolve in CI.
+Each commit on an eligible pull request is published to the [registry bridge](https://registry-bridge.viteplus.dev/). The bridge serves these builds as ordinary npm versions of the form `0.0.0-commit.<sha>` and proxies every other package to the npm registry. That means you install a preview with normal version specs instead of mutable URLs, and the same versions resolve in CI.
 
 Both `vite-plus` and `@voidzero-dev/vite-plus-core` publish under the same `0.0.0-commit.<sha>` version. Each pull request carries a comment listing the exact version for its latest commit, along with ready-to-copy install steps.
 

packages/cli/install.ps1

@@ -26,7 +26,7 @@ $LocalTgz = $env:VP_LOCAL_TGZ
 $LocalBinary = $env:VP_LOCAL_BINARY
 # PR number or commit SHA to install as a test build (registry bridge mode)
 $PrVersion = $env:VP_PR_VERSION
-# Registry bridge that serves pkg.pr.new builds as clearly-versioned packages.
+# Registry bridge that serves PR preview builds as clearly-versioned packages.
 # The pkg.pr.new-style download URL (BridgeDownloadBase) 302-redirects to a
 # canonical 0.0.0-commit.<sha> tarball; the registry (BridgeRegistry) resolves
 # those commit versions (and proxies everything else to npmjs) so a full install

packages/cli/install.sh

@@ -37,7 +37,7 @@ LOCAL_TGZ="${VP_LOCAL_TGZ:-}"
 LOCAL_BINARY="${VP_LOCAL_BINARY:-}"
 # PR number or commit SHA to install as a test build (registry bridge mode)
 PR_VERSION="${VP_PR_VERSION:-}"
-# Registry bridge that serves pkg.pr.new builds as clearly-versioned packages.
+# Registry bridge that serves PR preview builds as clearly-versioned packages.
 # The pkg.pr.new-style download URL (BRIDGE_DOWNLOAD_BASE) 302-redirects to a
 # canonical 0.0.0-commit.<sha> tarball; the registry (BRIDGE_REGISTRY) resolves
 # those commit versions (and proxies everything else to npmjs) so a full install

packages/cli/src/migration/migrator/package-json.ts

@@ -159,7 +159,7 @@ export function rewritePackageJson(
   if (isForceOverrideMode()) {
     for (const { dependencies } of dependencyGroups) {
       if (dependencies?.[VITE_PLUS_NAME]) {
-        // The referenced catalog entry is rewritten to the pkg.pr.new target
+        // The referenced catalog entry is rewritten to the preview target
         // separately. Preserve named/default catalog references so projects
         // such as Vize do not gain an unnecessary default catalog.
         if (

packages/cli/src/migration/migrator/vite-plus-bootstrap.ts

@@ -807,7 +807,7 @@ function ensureVitePlusDependencySpecs(
     }
     // Catalog writers update every existing managed entry in place. Keep a
     // package's deliberate named/default reference instead of collapsing all
-    // packages onto the workspace's preferred catalog, including pkg.pr.new
+    // packages onto the workspace's preferred catalog, including preview
     // force-override runs.
     if (version.startsWith('catalog:') && spec.startsWith('catalog:')) {
       continue;
@@ -823,7 +823,7 @@ function ensureVitePlusDependencySpecs(
     // Plain (non-protocol-pinned) range like `^0.1.24` → rewrite to the target
     // (`catalog:` for catalog-supporting projects, otherwise the concrete
     // version). Already-`catalog:` / other protocol pins are left untouched,
-    // except in force-override mode where ecosystem/pkg.pr.new validation must
+    // except in force-override mode where ecosystem/preview validation must
     // replace every prior target with the requested artifact.
     if (isForceOverrideMode() || !isProtocolPinnedSpec(spec)) {
       dependencies[VITE_PLUS_NAME] = version;