pnpm Workspaces & Private Flag: Should Workspace Root Privacy Implicitly Apply to Nested Packages?

Question

Problem Context
The private field in a package’s package.json is intended to prevent accidental public publishing. In a pnpm workspace, each package can declare its own privacy setting, but the workspace root’s private flag is not automatically propagated to nested packages. This can lead to confusion when a developer expects a single pnpm publish command to publish only the intended package(s).
Unresolved Decision
pnpm currently treats the private flag as a per‑package attribute. There is no documented enforcement that a workspace root marked "private": true will implicitly mark all child packages as private, unlike npm’s default behavior in some contexts. The community has debated whether such propagation should be added, but no consensus or implementation has been finalized as of the latest release.
Key Questions

Should pnpm automatically treat all packages within a workspace as private if the workspace root’s private flag is set?
If propagation is added, how would that affect existing projects that rely on mixed public/private packages within the same workspace?
What mechanisms would pnpm use to document and enforce this implicit privacy, and how would it interact with the --access flag during publishing?

Zoha · Answer

Answer
No. In pnpm, the private field is evaluated on a per‑package basis. A workspace root that declares "private": true does not automatically mark its child packages as private. Each nested package must have its own "private": true (or be excluded via a publish filter) to prevent accidental publishing.
Confirmed Facts (pnpm v9.x)

pnpm respects the private flag only on the package where it appears.
There is no built‑in configuration that propagates the root’s private setting to children.
Running pnpm publish --dry-run on a child without "private": true proceeds without a privacy warning.
Adding "private": true to the child causes a private package warning during the dry run.

Practical Steps to Verify Current Behavior

Check the root. Open packages/root/package.json (or the workspace root) and confirm "private": true is present.
Inspect a child. Open packages/child/package.json and look for the private field. If it is missing or set to false, the child is considered publishable.
Run a dry‑run. From the workspace root, execute:
pnpm publish --dry-run

If a child lacks private, pnpm will proceed without a warning. If you want to test the warning, add "private": true to that child and run the command again.

Use filters for mixed workspaces. If you have a mix of public and private packages, target only the public ones:
pnpm publish --filter "@myorg/public-package" --dry-run

Why the Root Does Not Implicitly Apply
pnpm’s design keeps the privacy declaration explicit to avoid accidental lock‑in of entire workspaces. This matches the npm community’s historical approach where only the package being published is checked for private. Implicit propagation would break projects that intentionally keep some workspaces public while keeping others private.
What If You Want Implicit Protection?
You can enforce it manually by adding "private": true to every child’s package.json, or by using a publish filter to exclude private packages. There is no configuration flag to enable automatic propagation at this time.

pnpm Workspaces & Private Flag: Should Workspace Root Privacy Implicitly Apply to Nested Packages?

Problem Context

Unresolved Decision

Key Questions

1 answer

Answer

Confirmed Facts (pnpm v9.x)

Practical Steps to Verify Current Behavior

Why the Root Does Not Implicitly Apply

What If You Want Implicit Protection?

Your perspective belongs here.

0 question comments