# Prepare Rslint NPM Release > Prepare a stable release PR for the unified rslint npm packages by updating package versions and rule/TypeScript release metadata. Use for release preparation or version bump PRs, not for publishing npm packages, canary releases, VS Code Marketplace releases, or the independent tsgo/Rust release line. - Skill: `web-infra-dev/prepare-rslint-npm-release` (Agent Skill) - Install (CLI): `npx skillmds@latest add web-infra-dev/prepare-rslint-npm-release` - Raw SKILL.md: https://api.skillmd.com/api/skills/web-infra-dev/prepare-rslint-npm-release/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: web-infra-dev (https://skillmd.com/u/web-infra-dev) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/web-infra-dev/prepare-rslint-npm-release --- # Prepare an Rslint npm Release PR Prepare a reviewable version and metadata PR, following the shape of [PR #2080](https://github.com/web-infra-dev/rslint/pull/2080). Use the current `pnpm sync:version-info` command introduced in #2078; #2080 used the older `sync:rule-releases` command and data filename. ## Establish the release state Follow the repository's [AGENTS.md](../../../AGENTS.md) for branches and local verification. Read these current sources before choosing commands or file scope: - [scripts/version.mjs](../../../scripts/version.mjs) and the root [package.json](../../../package.json): version calculation and package selection. - [scripts/sync-version-info/](../../../scripts/sync-version-info/): rule history and the pinned TypeScript commit/release mapping. - [Sync release information](../../../CONTRIBUTING.md#sync-release-information): the manual preparation sequence. Resolve the intended stable version or `major`, `minor`, or `patch` bump from the request. Ask for the target if it cannot be inferred. The version script bumps from the highest base version in its selected manifests, so inspect those versions before predicting the result. Fetch the main branch and release tags. Determine the previous stable `vX.Y.Z` tag, excluding prerelease tags, and check for an existing branch or PR for the requested release. Start new preparation from current `origin/main` on a branch such as `chore/release-`; resume an existing release branch instead of bumping again. If the target is already released, report that state rather than silently choosing another version. ## Update versions and metadata Run commands from the repository root. For an agreed patch release: ```bash pnpm run version patch pnpm sync:version-info ``` Use the requested bump type in place of `patch`. If the intended version bump is already present, skip the first command and review or refresh the metadata. `version` is not idempotent: running it again advances the version again. A failed metadata lookup is a reason to retry the sync after resolving the failure, not to repeat the bump. The version script owns the unified package selection: the root manifest, `packages/*/package.json` except `packages/tsgo/package.json`, and `npm/rslint/*/package.json`. This includes private workspace packages and the VS Code extension manifest; updating that manifest is part of version alignment, not a Marketplace release. Derive the current selection from the script rather than hardcoding #2080's package count. Preserve `workspace:` dependency ranges. The independent tsgo packages and Rust crate versions are outside this workflow. The sync writes `website/releases.json` for the new stable version. It reads the indexed `typescript-go` gitlink and queries upstream TypeScript tags. Record the compiler already pinned for this release; preparing a release does not imply a compiler upgrade. Stage any separately authorized submodule revision change before syncing. The sync can read the pin without initializing the submodule. The default sync skips when the package version equals the latest stable tag. An unexpected skip during new release preparation is not successful generation: check the package version and fetched tags. Use incremental sync for normal preparation; `full` rebuilds historical rule records and belongs to a separate history repair request. ## Review the generated diff Check these invariants before committing: - Every selected manifest has the intended version. Ordinary version changes affect only its `version` field; investigate unrelated dependency, script, formatting, or lockfile changes. - The new release appears once in `website/releases.json`. Earlier records and compiler bindings are unchanged, and no `main` entry or compiler backfill is introduced. - New rule IDs are unique and sorted. The list equals the registered rules added since the previous stable release, excluding IDs recorded in earlier releases. Cross-check implementations and the relevant core/plugin `all.go` aggregators for both missing and spurious entries; a helper or fixture directory is not a rule. A release with no new rules is valid. - `typescript.commit` equals the indexed gitlink. `typescript.releaseVersion` is an exact upstream tag match, including peeled annotated tags, or `null` when no tag matches. Do not substitute the latest TypeScript release or a version reported by upstream source files. - A second `pnpm sync:version-info` run leaves the generated file unchanged. For version and metadata-only changes, follow #2080's focused verification: run `pnpm run check-spell` with every changed text path explicitly, run `pnpm run format:check`, and run `git diff --check`. Apply AGENTS.md's affected package rules if source or build behavior also changes. The generic build/test suggestions printed by `version.mjs` are not a request for full local suites. ## Deliver the preparation PR Commit the version manifests and release metadata together, with a message and PR title such as `chore: release npm `. Push the release branch and open a PR targeting `main`, or update the existing release PR. Include the version transition, actual manifest count, new rule count, TypeScript binding, and the verification commands/results. Keep temporary verification artifacts outside the commit. This workflow ends at the preparation PR. Actual publication is a separate manual [release.yml](../../../.github/workflows/release.yml) workflow; merging a version PR does not publish npm packages. Its npm-only selection is `to_release=npm`. Draft release notes, when requested, use the separate [create-draft-release-notes skill](../create-draft-release-notes/SKILL.md).