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>
64 lines
2.8 KiB
Markdown
64 lines
2.8 KiB
Markdown
---
|
|
id: init
|
|
title: "pnpm init"
|
|
---
|
|
|
|
Create a `package.json` file.
|
|
|
|
## Options
|
|
|
|
### --bare
|
|
|
|
Added in: v10.25.0
|
|
|
|
Creates a `package.json` with only the required fields.
|
|
|
|
### --init-type <type\>
|
|
|
|
* Default: **module**
|
|
* Type: **commonjs**, **module**
|
|
|
|
Set the module system for the package.
|
|
|
|
### --init-package-manager
|
|
|
|
Pin the project to a pnpm version.
|
|
|
|
Since v11, the pin is written as a [`devEngines.packageManager`](../package_json.md#devenginespackagemanager) entry, so the resolved version is captured in `pnpm-lock.yaml`. Since v11.23.0 it is also written to the legacy `packageManager` field, as an exact version rather than a `^` range, because Corepack reads only `packageManager` and accepts nothing but an exact version.
|
|
|
|
Since v11.25.0, the pin can be newer than the pnpm that ran the command, so a project scaffolded by an outdated pnpm no longer inherits that staleness through its own pin ([#7490](https://github.com/pnpm/pnpm/issues/7490)). pnpm looks up the version published under the `latest` tag on the package-manager registries, and pins it **only when it is newer than the running version**. The lookup raises the pin, it never lowers it.
|
|
|
|
Two things follow from that. `latest` is a tag rather than "the newest release", so the pin tracks whichever line the tag points at: with `latest` on the pnpm 12 line, a pnpm 11.25 running `pnpm init` pins the newest pnpm 12, while a pnpm older than 11.25 predates the lookup and pins itself. And when the lookup cannot answer (no network, an unreachable or slow registry, `--offline`, or a `latest` that [`minimumReleaseAge`](../settings/dependency-resolution.md#minimumreleaseage) or [`trustPolicy`](../settings/dependency-resolution.md#trustpolicy) rejects), the running version is pinned, as before. The lookup never fails or hangs the command.
|
|
|
|
Inside a workspace subpackage this flag has no effect. The pin is only added to the workspace root's `package.json`, and the subpackage follows it. Pass `--no-init-package-manager` to scaffold a manifest with no pin at all.
|
|
|
|
## Configuration
|
|
|
|
These settings fill in fields of the scaffolded `package.json`. They may be set in `pnpm-workspace.yaml`, in the [global configuration file](./config.md), or through the environment as `PNPM_CONFIG_INIT_VERSION` and friends.
|
|
|
|
### initVersion
|
|
|
|
* Default: **1.0.0**
|
|
* Type: **String**
|
|
|
|
The `version` written into the new `package.json`.
|
|
|
|
### initLicense
|
|
|
|
* Default: **ISC**
|
|
* Type: **String**
|
|
|
|
The `license` written into the new `package.json`.
|
|
|
|
### initAuthorName, initAuthorEmail, initAuthorUrl
|
|
|
|
* Type: **String**
|
|
|
|
Assembled into the `author` field, in npm's `Name <email> (url)` form. A field left unset is left out of the string; with none of the three set, no `author` field is written.
|
|
|
|
```yaml title="pnpm-workspace.yaml"
|
|
initLicense: MIT
|
|
initAuthorName: Zoltan Kochan
|
|
initAuthorUrl: https://kochan.io
|
|
```
|