feat(global-cli): release support

[ubugeeei]

#1169

Note

These implementations are quite comprehensive and large in scope.
Feel free to treat them as reference implementations and narrow down the scope.

Summary

This PR introduces a new vp release workflow for monorepos and hardens it for real-world publishing.

The goal is to make workspace releases understandable, reviewable, and safer by default:

• plan versions from conventional commits
• support first-release onboarding
• surface readiness checks before publishing
• simulate native publish behavior during --dry-run
• keep local git state from advancing on failed publishes
• prefer trusted publishing and provenance-capable CI for real releases

What Changed

• Added a new vp release command to version and publish workspace packages.
• Added optional changelog generation for the workspace root and individual packages.
• Added prerelease support via --preid such as alpha, beta, and rc.
• Added package selection via --projects, while preserving user-specified order as a tie-breaker between independent packages.
• Added first-release guidance with an inline checklist for repository metadata, scoped package access, workflow setup, and CI validation.
• Added a built-in publish.yml template scaffold for first release when no publish/release workflow exists.
• Added readiness summaries for likely pre-release checks such as build, pack, prepack, prepublishOnly, prepare, and vitePlus.release.checkScripts.
• Added trusted publishing and provenance-aware policy checks for real releases.
• Added passkey/security-key-first guidance for manual fallback flows, with --otp treated as a legacy fallback.
• Added rollback-oriented artifact handling so durable release files are only written after publish succeeds.
• Added publish preflight support that rewrites temporary manifests, runs native publish dry-runs when possible, and restores local files afterward.
• Added support for release lifecycle metadata such as previous package names, previous paths, retired names, and extra release check scripts.
• Added shared release primitives in vite_shared for conventional commits, git helpers, versioning, and targeted package.json edits.
• Expanded unit coverage across release planning, reporting, workflow guidance, publish command resolution, versioning, and manifest editing.

Design Notes

• Release boundaries are tag-based. Real releases always create tags after a successful publish.
• Preview-only behavior such as --skip-publish and --no-git-tag is restricted to --dry-run.
• vp release does not implicitly run build or custom pre-release scripts. Instead, it reports likely checks and asks for confirmation.
• Real publishes are intended to run from trusted-publishing CI rather than an interactive local shell.
• Provenance is treated as part of the hardened release posture rather than an optional afterthought.
• The first-release scaffold defaults to workflow_dispatch, and branch/tag automation is left to repository-specific workflow policy.
• Release planning is rename-aware and path-aware so packages can evolve without losing release continuity.
• The implementation is intentionally split into smaller modules for orchestration, planning, reporting, storage/rollback, protocol safety, and first-release onboarding.

Usage

# Preview the release plan and native publish behavior
vp release --dry-run

# Preview only version/changelog work without publish simulation
vp release --dry-run --skip-publish

# First release flow with checklist and workflow scaffolding
vp release --first-release --dry-run

# Generate changelogs during the release flow
vp release --changelog --dry-run

# Publish a prerelease channel
vp release --preid alpha --dry-run

# Release a subset of packages
vp release --projects pkg-a,pkg-b --dry-run

# Non-interactive real release from CI
vp release --yes

Scope

This PR is intentionally broad because it introduces the full release surface rather than a thin CLI shim.

It covers:

• cli entrypoints and help text
• release planning and orchestration
• changelog generation
• trusted publishing and provenance checks
• first-release onboarding
• publish command resolution
• targeted package.json editing
• shared conventional-commit, git, and versioning utilities
• focused unit tests for the new release surface

Follow-ups

• Add end-to-end fixture coverage once the workspace manifest blocker is resolved.
• Consider adding fake-registry integration tests for multi-package publish failure scenarios.
• Consider documenting the recommended trusted-publishing workflow in more detail once the public release process settles.

[netlify]

✅ Deploy Preview for viteplus-preview canceled.

Name	Link
🔨 Latest commit	1f1fdb1
🔍 Latest deploy log	https://app.netlify.com/projects/viteplus-preview/deploys/69cab7d27921a900081e39ad

[ubugeeei]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c43ffa0b44

ℹ️ 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".

[chatgpt-codex-connector]

Push the release commit, not only tags, in CI workflow

vp release --yes creates a local release commit before tagging (see run_release in manager.rs), but this scaffold only executes git push origin --tags. In a branch-based workflow that means version/changelog manifest updates never land on the branch, so the next run plans from stale package.json versions and can produce duplicate or regressive publish versions. Push HEAD (or the release branch) together with tags so branch state stays consistent with the published tags.

Useful? React with 👍 / 👎.

[ubugeeei]

NOTE: I temporarily removed the Draft status to try triggering a review with Codex, but it is still a draft.

[ubugeeei]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c3c9209675

ℹ️ 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".

[chatgpt-codex-connector]

Rewrite package version from manifest content, not computed tag version

When a package keeps "version": "0.0.0" and relies on git tags for the real current version, plan.current_version can be 1.x.y while the manifest still contains 0.0.0. This code uses plan.current_version as the expected old value for replace_top_level_string_property, so the rewrite fails with an "Expected 'version' to be ..." error before publish. That makes subsequent releases fail for the tag-sourced workflow the planner explicitly supports.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Avoid creating workflow files during dry-run planning

This always calls ensure_first_publish_workflow_template during presentation, even for --dry-run. In a first-release dry-run with no existing publish workflow, it writes .github/workflows/publish.yml, which violates the dry-run contract and dirties the worktree; the same run can then skip native publish preflight because run_dry_run requires a clean tree. Gate this scaffolding behind non-dry-run (or an explicit opt-in) to keep dry-run side-effect free.

Useful? React with 👍 / 👎.