* 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>
Update the Reporting a Vulnerability section in SECURITY.md to clarify that GitHub Security Advisories and private vulnerability reporting are not used, and that security vulnerabilities should be filed as regular public bug reports in this repository.
Clarify that static configuration settings in repository-level .npmrc or
pnpm-workspace.yaml (such as strict-ssl=false, cafile, registry, or proxies)
are standard package manager configuration supported by npm and Yarn for
enterprise and intranet deployments. Suppressing or ignoring these literal
settings would be a breaking change and diverges from upstream package managers,
so these configurations are considered out of scope.
A packages: entry pointing outside the workspace root (../shared,
../../docs/*) was silently dropped from the project list.
normalize_manifest_patterns turns it into ../shared/package.json and
hands it to wax, whose globs cannot express parent traversal, so a walk
rooted at the workspace root matched nothing and raised no error.
The declared project never reached the install's project list, which is
what trusted_importer_ids is built from, so a lockfile pnpm 11 wrote for
the same workspace failed with
ERR_PNPM_PACKAGE_MANAGER_UNSAFE_IMPORTER_PATH on its ../shared importer
key. pnpm list -r and --filter did not see the package either.
Discovery now strips the leading ../ components off each normalized
pattern and starts the walk from the ancestor they name, keeping the
glob handed to wax traversal free. A pattern that climbs past the
filesystem root matches nothing. A walk can therefore start above the
workspace root, while a ! pattern stays written relative to the
workspace root, so user negations moved out of Walk::not and are matched
against each entry's path from the workspace root instead.
pacquet only: the TypeScript CLI globs through tinyglobby, which handles
the parent-relative form already.
Closespnpm/pnpm#13880.
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
* docs(security): state the untrusted-repository trust boundary
The threat model section only described the filesystem-permissions tier,
so it was silent on the tier that reports actually target: a repository
the user clones and then runs pnpm inside.
pnpm defends part of that tier — a plain install must not send
credentials to a repository-chosen host, and must not run unapproved
dependency build scripts — which is why environment variable expansion
in repository-controlled configuration is gated for request destinations
and auth values. Because that gate is real but partial, a setting
missing from it reads as an oversight rather than as a setting that was
never in scope. A recent advisory reported exactly that about
`nodeOptions`, which only takes effect for `pnpm run` and `pnpm exec` —
commands that execute repository-chosen code regardless, and which
honor a literal value with no placeholder at all.
Name the boundary, list the two out-of-scope classes it implies, and ask
reporters of gate-coverage gaps for the counterfactual: what the gap
buys an attacker beyond what they could already do without it.
* docs(security): correct what a plain install defends
The previous wording claimed installing from an untrusted repository is
a defended act, distinct from running its code. It is not: a plain
`pnpm install` runs the project's own preinstall/install/postinstall/
prepare scripts, gated only by `ignoreScripts` (default false) at
installing/deps-installer/src/install/index.ts. The build approval
mechanism never reaches runLifecycleHooksConcurrently — `allowBuild` is
passed to buildModules and `_rebuild` only, so it gates dependencies'
build scripts and not the installed project's own.
Describe the env expansion restrictions as what they are: hardening that
narrows silent credential exfiltration in the --ignore-scripts case and
in review workflows where a config diff draws less scrutiny than a new
postinstall script, rather than a boundary whose coverage gaps are
vulnerabilities by themselves.
Pure directory move plus path fixups: the Rust port ships as pnpm v12,
so the source tree now lives at pnpm/ (alongside pnpm11/, the frozen
TypeScript line). No identifiers change in this pass — crate names
(pacquet-*), the pacquet bin, PACQUET_VERSION, the @pacquet/* npm
package names v11's runPacquet spawns, the .pacquet virtual-store dir,
the benchmark harness's clone dir, and the pacquet-*.yml workflow
filenames (npm trusted publishing is bound to them) all stay for a
follow-up.
Also removes the root /pnpm/ .gitignore entry (build detritus in the
pre-pnpm11 package location): pnpm/ is real source now and must not be
ignored. Developers with a stale generated pnpm/ dir should delete it
before checking out this change.
* docs: document threat model and trust boundaries in security policy
Clarify that pnpm's security boundary is filesystem permissions and that
reports assuming pre-existing write access to the store, lockfile,
node_modules, or config files are out of scope. Explain that the
content-addressable store's integrity check is corruption detection, not
tamper resistance against a write-capable local adversary, since the
recorded hashes live in the same trust domain as the files.
* docs: route pacquet and pnpr security reports to regular issues
