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>
72 lines
2.7 KiB
Markdown
72 lines
2.7 KiB
Markdown
---
|
|
id: scripts
|
|
title: Scripts
|
|
---
|
|
|
|
How pnpm handles the `scripts` field of `package.json`.
|
|
|
|
## Hidden scripts
|
|
|
|
Added in: v11.0.0
|
|
|
|
Scripts with names starting with `.` are hidden. They cannot be run directly via `pnpm run` and are omitted from the `pnpm run` listing. Hidden scripts can only be called from other scripts.
|
|
|
|
```json title="package.json"
|
|
{
|
|
"scripts": {
|
|
".helper": "echo 'I am hidden'",
|
|
"build": "pnpm run .helper && tsc"
|
|
}
|
|
}
|
|
```
|
|
|
|
In this example, `pnpm run .helper` would fail, but `pnpm run build` would succeed because `.helper` is called from another script.
|
|
|
|
## Environment variables
|
|
|
|
pnpm sets the following environment variables during lifecycle script execution:
|
|
|
|
- `npm_package_name`: the package name
|
|
- `npm_package_version`: the package version
|
|
- `npm_lifecycle_event`: the name of the running script (e.g., `postinstall`)
|
|
|
|
:::note
|
|
|
|
Since v11, pnpm no longer populates `npm_config_*` environment variables from the pnpm configuration. Only the well-known `npm_*` variables above are set, matching Yarn's behavior.
|
|
|
|
:::
|
|
|
|
## Built-in command and script name conflicts
|
|
|
|
Added in: v11.0.0
|
|
|
|
The following built-in commands prefer user scripts: `clean`, `setup`, `deploy`, and `rebuild`. If your `package.json` defines a script with one of these names, `pnpm <name>` will execute the script instead of the built-in command.
|
|
|
|
To force the built-in command, use [`pnpm pm <name>`](./cli/pm.md).
|
|
|
|
## Lifecycle scripts
|
|
|
|
### `pnpm:devPreinstall`
|
|
|
|
Runs when `pnpm install` runs in the project itself, including in CI. It does not run when the package is installed as a dependency of another project.
|
|
|
|
Runs before any dependency is installed.
|
|
|
|
This script is executed only when set in the root project's `package.json`.
|
|
|
|
Since v11.28.0, installs that skip `devDependencies`, such as `pnpm install --prod`, do not run it.
|
|
|
|
### `preinstall` of the root project
|
|
|
|
Since v11.28.0, the root project's `preinstall` script runs before dependencies are resolved and linked. A guard such as `npx only-allow pnpm` can therefore stop the install before pnpm populates `node_modules`.
|
|
|
|
### `prepare`
|
|
|
|
The root project's `prepare` script runs after `pnpm install`. It is skipped, since v11.28.0, by installs that skip `devDependencies` (such as `pnpm install --prod`), by `pnpm install` given package arguments, and for the project that [`pnpm deploy`](./cli/deploy.md) deploys.
|
|
|
|
### Uninstall scripts
|
|
|
|
Added in: v11.28.0
|
|
|
|
[`pnpm remove`](./cli/remove.md) runs the project's own `preuninstall`, `uninstall`, and `postuninstall` scripts. `preuninstall` and `uninstall` run before dependencies are unlinked, and a failure in either aborts the removal. `postuninstall` runs after unlinking completes. The [`ignoreScripts`](./settings/build.md#ignorescripts) setting and `--lockfile-only` skip all three.
|