Skip to main content

release

Run the dev-process-kit release flow end-to-end. Use when the user asks to release patch, minor, major, beta, or an explicit semver; bumps the version with `npm version`, pushes the signed tag, watches the Release workflow that publishes to npm, and publishes the GitHub Release.

معلومات المصدر

المستودع
d-kimuson/dev-process-kit
آخر نشاط في المصدر
٢٤ سبتمبر ٢٠٢٦ في ٠٢:٣٠
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٤
التفرعات
٠

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
release
description
Run the dev-process-kit release flow end-to-end. Use when the user asks to release patch, minor, major, beta, or an explicit semver; bumps the version with `npm version`, pushes the signed tag, watches the Release workflow that publishes to npm, and publishes the GitHub Release.
metadata
{"internal":true}
# dev-process-kit Release A release is a version of the npm package `dev-process-kit`. Pages load it from jsDelivr pinned to that exact version, and its documentation is `docs/` at the `v<version>` tag, so a published version is never changed: a fix is a new version. ## Inputs Interpret the user's argument as the release version spec: | Spec | `npm version` argument | Example | | --------------------------- | ------------------------- | ------------------------------------------------- | | `patch` / `minor` / `major` | the same | `0.1.0` → `0.1.1`; `0.1.1-beta.2` → `0.1.1` | | `beta` | `prerelease --preid beta` | `0.1.0` → `0.1.1-beta.0`; `…-beta.0` → `…-beta.1` | | an explicit semver | the version | `0.2.0`, `0.2.0-beta.0` | If no version spec is present, ask the user which one to use. A `beta` goes to the npm dist-tag `beta`, so `@latest` is untouched; use it to try a build from a real Artifact before releasing it. ## Preconditions 1. Work from the repository root on `main`, with a clean working tree: ```bash git branch --show-current git status --short ``` 2. If there are unrelated uncommitted changes, stop and ask the user how to handle them. Commit release-related changes first: `npm version` refuses a dirty tree. 3. The commit and the tag are signed with SSH: ```bash git config --get gpg.format # ssh git config --get commit.gpgsign # true git config --get tag.gpgsign # true ``` 4. The npm package exists and has a trusted publisher for `.github/workflows/release.yml`. The first version is published by hand, because npm cannot configure a trusted publisher for a package that does not exist yet. ## Release command ```bash npm version <argument> -m "chore: release v%s" git push --follow-tags ``` `npm version` runs the `preversion` script first (lint, typecheck, test, build), then updates `package.json`, creates the signed commit `chore: release v<version>` and the signed annotated tag `v<version>`. `--follow-tags` pushes the commit together with that tag. If the push fails, the commit and the tag already exist locally. Fix the cause and push again; do not rerun `npm version`. ## Monitor GitHub Actions The tag triggers the Release workflow, which builds, strips the development fields from `package.json` (`clean-pkg-json`) and publishes with provenance under the dist-tag of the version (`latest`, or `beta` for a prerelease). ```bash TAG="v0.0.0" # replace RUN_ID="$(gh run list --workflow Release --limit 20 --json databaseId,headBranch,event --jq ".[] | select(.headBranch == \"$TAG\" and .event == \"push\") | .databaseId" | head -n 1)" test -n "$RUN_ID" && gh run watch "$RUN_ID" --exit-status ``` If the workflow fails, inspect the logs before taking corrective action: ```bash gh run view "$RUN_ID" --log-failed ``` A version npm has not published can be retried by rerunning the workflow. Once npm has it, the number is spent: release the fix as the next version. ## Verify publish ```bash VERSION="0.0.0" # replace npm view "dev-process-kit@$VERSION" version npm dist-tag ls dev-process-kit curl -sfI "https://cdn.jsdelivr.net/npm/dev-process-kit@$VERSION/dist/index.js" | head -n 1 curl -sfI "https://raw.githubusercontent.com/d-kimuson/dev-process-kit/v$VERSION/docs/index.md" | head -n 1 ``` The last two are what a consumer loads: the bundle from jsDelivr and the documentation at the tag. ## GitHub Release Create the release from the tag with generated notes as a draft, then rewrite the notes: ```bash TAG="v0.0.0" # replace gh release create "$TAG" --verify-tag --draft --generate-notes $([[ "$TAG" == *-* ]] && echo --prerelease) gh release view "$TAG" --json body --jq .body ``` Rewrite the notes for people who generate pages with dev-process-kit: - Use concise, user-focused English. - Prefer these sections when relevant: `Features`, `Bug Fixes`, `Breaking Changes`, `Internal`. - Describe the impact on pages and on the public contract (elements, attributes, events, slots), not implementation details. - Remove trivial items such as formatting, typo-only, dependency-only and purely internal refactors unless they affect users. - Merge intermediate same-release fixes into their related feature or fix. Publish the draft with the rewritten notes: ```bash NOTES_FILE="/tmp/dev-process-kit-$TAG-release-notes.md" # write it with the file tool gh release edit "$TAG" --notes-file "$NOTES_FILE" --draft=false gh release view "$TAG" --json tagName,isDraft,isPrerelease,url ``` ## Final report Report: - released tag/version and its npm dist-tag - the `npm version` command used - GitHub Actions run ID and result - npm and jsDelivr verification results - GitHub Release URL and draft/public state - any follow-up commits created for release automation or this skill
عرض على GitHub