Zoltan KochanandClaude Opus 5.5
6f95957063
* docs: lint prose with Vale Add Vale with an in-repo style, .vale/styles/pnpm, that turns the writing rules in AGENTS.md and the Google developer documentation style guide into lint rules. The stock Vale packages (Google, Microsoft, RedHat, write-good) were too noisy to block on, for example 1,300 passive-voice hits in the v12 docs alone, so the rules are written for this repo, following the GitLab model. Each one links the guideline it enforces. Levels: - error, fails CI: dashes, plain-word substitutions, condescending words, "please", "note that", hedges, puffery, optional plurals, exclamation marks, ellipses, curly quotes, generic link text, product spellings, sentence-case headings, repeated words, double spaces, implementation history in comments; in changesets, bold or italic emphasis, internal names and release-line names. - warning: future tense, sentences over 30 words, "instead of" and "so that" tails in changesets. - suggestion: passive voice. .vale.ini scopes the rules. Docs get every rule. Contributor Markdown and code comments keep dashes and headings as warnings until their roughly 8,100 em dashes are rewritten. Released changesets stay in .changeset/ and are not rewritten, so lint-prose.mjs lints only the changesets added since PROSE_BASE (the PR base in CI). The prose workflow installs a pinned, checksum-verified Vale release and runs `pnpm lint:prose`. The rest of this change rewrites the existing docs, READMEs, contributor Markdown, and code comments to pass the error-level rules. Only prose and comment text changed. Renamed headings keep their anchors. Spelling stays with cspell, which checks identifiers that Vale does not see. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: keep prose lint from flattening meaning --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2.3 KiB
id, title
| id | title |
|---|---|
| lane | pnpm lane |
Added in: v11.13.0
Manages per-package release lanes. A lane is a parallel release track: while a package is on one, the bare pnpm version -r releases it as X.Y.Z-<lane>.N prereleases while the rest of the workspace keeps releasing stable versions. Moving a package back to the main lane releases its accumulated stable version on the next run.
pnpm lane
pnpm lane <name> --filter <pattern>
pnpm lane main --filter <pattern>
Membership lives under the versioning.lanes key of pnpm-workspace.yaml; this command is a convenience editor for that key.
Usage
Show lane membership
pnpm lane
Lanes:
alpha:
@example/cli
@example/napi
If no package has been assigned a lane, this prints All packages are on the main lane.
Move packages onto a lane
pnpm lane alpha --filter @example/cli
--filter is required. It selects the packages to move. Lane names may contain only alphanumerics and hyphens, and cannot be purely numeric.
Move packages back to the main lane
pnpm lane main --filter @example/cli
main is the reserved name of the default lane. Every package is on it unless assigned elsewhere, and packages on it release stable versions. Graduating a package releases the stable version its prereleases were building toward on the next pnpm version -r run.
Versions on a lane
A package on a lane releases X.Y.Z-<lane>.N, where X.Y.Z is the stable version the lane is building toward and N counts up from 0:
| Current version | Pending intent | Lane | New version |
|---|---|---|---|
2.0.0 |
minor | alpha |
2.1.0-alpha.0 |
2.1.0-alpha.0 |
patch | alpha |
2.1.0-alpha.1 |
2.1.0-alpha.1 |
major | alpha |
3.0.0-alpha.0 |
3.0.0-alpha.0 |
none | main |
3.0.0 |
N restarts at 0 whenever the stable target changes. When a bump escalates the target (a major intent while the lane was building a minor), the target is recomputed and the counter resets.
Packages in the same fixed group must move between lanes together.
Options
--filter <package_selector>
Select the packages to move between lanes. Required when assigning a lane.