antd-mobile-release

Ant Design Mobile release

Applies to ant-design/ant-design-mobile npm packages and GitHub Releases. When the user requests "release preparation", first confirm the version, then complete dependencies, build, checks, and the version commit;the user only runs the npm publish command manually. After the user reports that publishing is complete, the Agent verifies the npm package, then creates the tag and the GitHub Release.

First confirm the version

1. Read-only check of the current branch, working tree, latest master, existing Git tags, GitHub Releases, npm versions and dist-tags, and changes since the last release. If there are existing uncommitted changes, first determine their ownership and do not overwrite the user's work.
2. Based on the nature of the changes, recommend one clear target version, briefly explain the reason for the recommendation, and directly ask the user whether to adopt that version; the user may also specify another version. Stable releases cannot reuse the current -alpha version number; pre-releases must specify the explicit version number and the alpha or dev tag.
3. Only after obtaining the user's explicit confirmation of the target version, modify files, install dependencies, compile, commit, or push. Confirm that the target version is not already used for the npm package, Git tag, or GitHub Release.

After confirmation, perform the preparation

1. Based on the latest master, check the working tree and remote CI. Install dependencies according to the lockfile, use Node.js and pnpm versions compatible with the project, and do not casually upgrade dependencies or modify package management configuration.
2. Change package.json to the confirmed target version. Run pnpm build, the applicable tests and Lint,pnpm package-diff and npm pack --dry-run ./lib, and verify that lib/package.json matches the target version and the files to be released; if it fails, fix it first and re-verify, and do not commit with failing results.
3. Commit only the files related to this release. The version commit title must state the full target version, use chore: release v<version>, for example chore: release v5.43.0; do not use generalized titles such as chore: change version that do not contain a version number. After committing, verify that the title matches the package.json version, then push to origin/master, verify that the remote commit matches the local one, and report the remote CI status. If it cannot be safely updated or pushed, explain the blocker and do not overwrite others' changes.
4. Compile the changes since the last stable release, and prepare concise Chinese and English GitHub Release notes and related PR links. Ensure that the user's working directory already contains the correct version of ./lib, and that Node.js, pnpm, and the npm registry can be used directly for publishing; during the preparation phase,do not create or push tags, do not run the publish command, and do not create a GitHub Release. Report the version, commits, and check results, then only prompt stable-release users to enter pnpm pub. If the user explicitly chooses a pre-release version, switch to the corresponding pnpm pub:alpha or pnpm pub:dev。

After the user completes the manual publish

1. After the user reports that publishing is complete, verify the actual package version and dist-tag from the target npm registry; the stable release should become latest. After a successful npm publish, it may take time to become visible. If the target version cannot be found temporarily or the tag still points to an old version, first check the publish command output and the registry, then re-query every 30–60 seconds and report the waiting status to the user. Do not treat a temporary 404 as a publish failure. Before confirming that the target version and tag are visible, do not create a tag or a Release, and do not retry the npm publish on the user's behalf; if it remains invisible for a long time, then investigate the publish result.
2. Confirm that the remote master contains the version commit. On thatversion commitcreate and push the v<version> tag; if the tag already exists, verify its target, reuse it if correct, and if incorrect resolve the conflict first without moving an already-published tag.
3. Use the prepared Chinese and English changelog to create a GitHub Release on that tag; if the Release already exists, verify and update the title, body, and tag, and do not create a duplicate Release. Then verify the npm package, dist-tag, remote tag, and Release, and follow up on the Doc Site workflow triggered by the Release until the result is clear.

pnpm pub will first run the repository's package-diff, then publish ./lib. If the diff check reports missing files, verify the cause first and do not confirm directly. If any publish action fails, first record the completed steps and the remote state, and do not retry blindly to avoid duplicate publishing.