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>
1.5 KiB
id, title
| id | title |
|---|---|
| aliases | Aliases |
Aliases let you install packages with custom names.
Let's assume you use lodash all over your project. There is a bug in lodash
that breaks your project. You have a fix but lodash won't merge it. Normally
you would either install lodash from your fork directly (as a git-hosted
dependency) or publish it with a different name. If you use the second solution
you have to replace all the requires in your project with the new dependency
name (require('lodash') => require('awesome-lodash')). With aliases, you
have a third option.
Publish a new package called awesome-lodash and install it using lodash as
its alias:
pnpm add lodash@npm:awesome-lodash
No changes in code are needed. All the requires of lodash will now resolve to
awesome-lodash.
Sometimes you'll want to use two different versions of a package in your project. Easy:
pnpm add lodash1@npm:lodash@1
pnpm add lodash2@npm:lodash@2
Now you can require the first version of lodash via require('lodash1') and the
second via require('lodash2').
This gets even more useful when combined with hooks. Maybe you want to replace
lodash with awesome-lodash in all the packages in node_modules. You can
easily achieve that with the following .pnpmfile.mjs:
function readPackage(pkg) {
if (pkg.dependencies && pkg.dependencies.lodash) {
pkg.dependencies.lodash = 'npm:awesome-lodash@^1.0.0'
}
return pkg
}
export const hooks = {
readPackage
}