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 |
|---|---|
| exec | pnpm exec |
Execute a shell command in scope of a project.
node_modules/.bin is added to the PATH, so pnpm exec allows executing commands of dependencies.
Examples
If you have Jest as a dependency of your project, there is no need to install Jest globally. Run it with pnpm exec:
pnpm exec jest
The exec part is actually optional when the command is not in conflict with a builtin pnpm command, so you may also run:
pnpm jest
Options
Any options for the exec command should be listed before the exec keyword.
Options listed after the exec keyword are passed to the executed command.
Good. pnpm will run recursively:
pnpm -r exec jest
Bad, pnpm will not run recursively but jest will be executed with the -r option:
pnpm exec jest -r
--recursive, -r
Execute the shell command in every project of the workspace.
The name of the current package is available through the environment variable
PNPM_PACKAGE_NAME.
Examples
Prune node_modules installations for all packages:
pnpm -r exec rm -rf node_modules
View package information for all packages. This should be used with the --shell-mode (or -c) option for the environment variable to work.
pnpm -rc exec pnpm view \$PNPM_PACKAGE_NAME
--no-reporter-hide-prefix
Do not hide prefix when running commands in parallel.
--resume-from <package_name>
Resume execution at a particular project. pnpm skips the projects a matching
record of the previous recursive exec says already passed. Without such a
record, it omits the named project's transitive dependencies, but still runs
the named project, its dependents, and unrelated projects in the selected
graph. See Workspace task
orchestration.
--parallel
Completely disregard concurrency and topological sorting, running a given script immediately in all matching packages. This is the preferred flag for long-running processes over many packages, for instance, a lengthy build process.
--shell-mode, -c
Runs the command inside of a shell. Uses /bin/sh on UNIX and \cmd.exe on Windows.
--report-summary
Read about this option in the run command docs