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.2 KiB
id, title
| id | title |
|---|---|
| pack | pnpm pack |
Create a tarball from a package.
Since v11.28.0:
bundleDependenciesare included when using the isolated linker, including bundled workspace packages and the dependencies of each bundled package, and also whenpublishConfig.directoryselects a build directory.- Symlinks that point to files or directories included in the package are kept. Symlinks that point outside the package are left out.
- Executable permissions of the source files are preserved in the tarball.
- When the project uses a
package.yamlorpackage.json5manifest, itsfilesfield is honored and the tarball contains exactly onepackage.json.
Options
--recursive, -r
Added in: v10.11.0
Pack all packages from the workspace.
--out <path>
Customizes the output path for the tarball. Use %s and %v to include the package name and version, e.g., %s.tgz or some-dir/%s-%v.tgz. By default, the tarball is saved in the current working directory with the name <package-name>-<version>.tgz.
--pack-destination <dir>
Directory in which pnpm pack will save tarballs. The default is the current working directory.
--pack-gzip-level <level>
Specifying custom compression level.
--json
Log output in JSON format.
--filter <package_selector>
Added in: v10.11.0
--dry-run
Added in: v10.26.0
Does everything a normal run does, except actually packing the tarball. Useful for verifying the contents of the tarball.
--skip-manifest-obfuscation
Added in: v11.3.0
Keep the original packageManager field and publish lifecycle scripts in the packed manifest instead of stripping them. The pnpm-specific pnpm field is still omitted.
Life cycle scripts
prepackpreparepostpack
:::tip
You can also use the beforePacking hook to programmatically modify the package.json contents before the tarball is created. This is useful for removing development-only fields or adding publication metadata without modifying your local package.json.
:::