* 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>
4.2 KiB
id, title
| id | title |
|---|---|
| config | pnpm config |
Aliases: c
Manage the configuration files.
pnpm settings are split across two kinds of configuration files:
- Registry and authentication settings live in INI files: the global
rcfile,auth.ini, and local.npmrcfiles. - All other pnpm settings live in YAML files: the global
config.yamland the per-projectpnpm-workspace.yaml.
The local workspace configuration file is located at the root of the project and is named pnpm-workspace.yaml. The global YAML configuration file (config.yaml) is located at:
- If the $XDG_CONFIG_HOME env variable is set, then $XDG_CONFIG_HOME/pnpm/config.yaml
- On Windows: ~/AppData/Local/pnpm/config/config.yaml
- On macOS: ~/Library/Preferences/pnpm/config.yaml
- On Linux: ~/.config/pnpm/config.yaml
The global rc file (registry/auth settings only) is at:
- If the $XDG_CONFIG_HOME env variable is set, then $XDG_CONFIG_HOME/pnpm/rc
- On Windows: ~/AppData/Local/pnpm/config/rc
- On macOS: ~/Library/Preferences/pnpm/rc
- On Linux: ~/.config/pnpm/rc
You can also retrieve the path to your global config file by running (added in v10.21.0):
pnpm config get globalconfig
Commands
set <key> <value>
Set the config key to the value provided.
Without the --json flag, it parses the value as plain string:
pnpm config set --location=project nodeVersion 22.0.0
With the --json flag, it parses the value as JSON:
pnpm config set --location=project --json nodeVersion '"22.0.0"'
The --json flag also allows pnpm config set to create arrays and objects:
pnpm config set --location=project --json allowBuilds '{"react": true, "react-dom": true}'
pnpm config set --location=project --json catalog '{ "react": "19" }'
The set command does not accept a property path.
Since v11.22.0, pnpm config set refuses to write a setting to a project's pnpm-workspace.yaml that pnpm does not read from there, such as configDir, pnpmHomeDir, stateDir, and the other settings that name machine-level state. Since v11.25.0, this includes scope, which controls the machine-wide default for pnpm login. The command fails with ERR_PNPM_CONFIG_SET_NOT_A_PROJECT_SETTING, naming where the setting belongs when it belongs somewhere. pnpm config delete still clears such a key from a file that already carries it.
get <key>
Print the config value for the provided key.
The key can be a simple key:
pnpm config get nodeVersion
pnpm config get --json nodeVersion
pnpm config get --json packageExtensions
pnpm config get --json allowBuilds
pnpm config get --json catalog
It can also be a property path:
pnpm config get 'packageExtensions["@babel/parser"].peerDependencies["@babel/types"]'
pnpm config get --json 'packageExtensions["@babel/parser"].peerDependencies["@babel/types"]'
pnpm config get 'allowBuilds.react'
pnpm config get --json 'allowBuilds.react'
pnpm config get catalog.react
pnpm config get --json catalog.react
The syntax of the property path emulates JavaScript property paths.
delete <key>
Remove the config key from the config file.
list
Show all the config settings. Output is a JSON object.
Auth-related settings are hidden from the output; use pnpm config get <key> to read them explicitly.
:::note
Since v11, pnpm config get (without --json) no longer prints INI-formatted text. It prints JSON for objects and arrays, and raw strings for strings, numbers, booleans, and nulls. pnpm config get --json prints all values as JSON. pnpm config list always prints a JSON object.
:::
Options
--global, -g
Set the configuration in the global config file.
With get and list, show the global configuration without the settings from the project's pnpm-workspace.yaml and .npmrc.
--location
By default, --location is set to global.
When set to project, pnpm writes the setting to pnpm-workspace.yaml at the workspace root (or, for registry/auth settings, to the .npmrc in the workspace root).
When set to global, the behavior is the same as passing the --global option.
--json
Make get and list show all the config settings in JSON format and make set parse the value as JSON.