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>
3.8 KiB
id, title
| id | title |
|---|---|
| link | pnpm link |
Aliases: ln
Links a local package to the current project's node_modules.
pnpm link <dir>
Options
pnpm link <dir>
Links package from <dir> directory to node_modules of package from where you're executing this command. <dir> must be a relative or absolute path.
For example, if you are inside
~/projects/fooand you executepnpm link ../bar, then a link tobarwill be created infoo/node_modules/bar.
:::note Breaking changes in v11
pnpm link no longer resolves packages from the global store. Only relative or absolute paths are accepted (use pnpm link ./foo instead of pnpm link foo).
pnpm link --global has been removed. To register a local package's bins globally, use pnpm add -g . instead.
pnpm link with no arguments has been removed. Always pass an explicit path.
:::
Use cases
Replace an installed package with a local version of it
Let's say you have a project that uses foo package. You want to make changes to foo and test them in your project. In this scenario, you can use pnpm link to link the local version of foo to your project:
cd ~/projects/foo
pnpm install # install dependencies of foo
cd ~/projects/my-project
pnpm link ~/projects/foo # link foo to my-project
Add a binary globally
To make a local package's binaries available system-wide, use pnpm add -g . instead:
cd ~/projects/foo
pnpm install # install dependencies of foo
pnpm add -g . # register foo's bins globally
Remember that the binary will be available only if the package has a bin field in its package.json.
What's the difference between pnpm link and using the file: protocol?
When you use pnpm link, the linked package is symlinked from the source code. You can modify the source code of the linked package, and the changes will be reflected in your project. With this method pnpm will not install the dependencies of the linked package, you will have to install them manually in the source code. This may be useful when you have to use a specific package manager for the linked package, for example, if you want to use npm for the linked package, but pnpm for your project.
When you use the file: protocol in dependencies, the linked package is hard-linked to your project node_modules, you can modify the source code of the linked package, and the changes will be reflected in your project. With this method pnpm will also install the dependencies of the linked package, overriding the node_modules of the linked package.
:::info
When dealing with peer dependencies it is recommended to use the file: protocol. It better resolves the peer dependencies from the project dependencies, ensuring that the linked dependency correctly uses the versions of the dependencies specified in your main project, leading to more consistent and expected behaviors.
:::
| Feature | pnpm link |
file: Protocol |
|---|---|---|
| Symlink/Hard-link | Symlink | Hard-link |
| Reflects source code modifications | Yes | Yes |
| Installs dependencies of the linked package | No (manual installation required) | Yes (overrides node_modules of the linked package) |
| Use different package manager for dependency | Possible (e.g., use npm for linked pkg) |
No, it will use pnpm |