mirror of https://github.com/pnpm/pnpm.git synced 2026-06-28 09:55:39 -04:00

Files

Zoltan Kochan 681b593eb2 fix: support scope-specific registry auth tokens (#12392 )

pnpm can now use different auth tokens for different package scopes, even when those scopes use the same registry URL.

Previously, auth was selected only by registry URL. If `@org-a` and `@org-b` both used `https://npm.pkg.github.com/`, they had to share the same token. This caused problems for registries that issue tokens per organization or per scope.

Configure a scope-specific token by adding the package scope after the registry URL in the auth key:

```ini
@org-a:registry=https://npm.pkg.github.com/
@org-b:registry=https://npm.pkg.github.com/

//npm.pkg.github.com/:@org-a:_authToken=${ORG_A_TOKEN}
//npm.pkg.github.com/:@org-b:_authToken=${ORG_B_TOKEN}

//npm.pkg.github.com/:_authToken=${FALLBACK_TOKEN}
```

`pnpm login --registry=https://npm.pkg.github.com --scope=@org-a` writes the token to the same scope-specific auth key.

When installing or publishing `@org-a/*`, pnpm uses `ORG_A_TOKEN`. For `@org-b/*`, pnpm uses `ORG_B_TOKEN`. Packages without a matching scope continue to use the registry-wide fallback token.

2026-06-14 11:43:30 +02:00

src

fix: support scope-specific registry auth tokens (#12392 )

2026-06-14 11:43:30 +02:00

.gitignore

refactor: rename the agent client and agent setting to pnpr (#12155 )

2026-06-03 12:01:48 +02:00

CHANGELOG.md

chore(release): 11.5.3 (#12305 )

2026-06-10 12:40:29 +02:00

package.json

chore(release): 11.5.3 (#12305 )

2026-06-10 12:40:29 +02:00

README.md

perf(pnpr): resolve server-side and fetch tarballs directly (#12232 )

2026-06-06 02:16:33 +02:00

tsconfig.json

perf(pnpr): resolve server-side and fetch tarballs directly (#12232 )

2026-06-06 02:16:33 +02:00

tsconfig.lint.json

refactor: rename the agent client and agent setting to pnpr (#12155 )

2026-06-03 12:01:48 +02:00

README.md

@pnpm/pnpr.client

Client library for the pnpr server. Resolves a project's dependencies server-side and returns the resolved lockfile.

How it works

Sends POST /v1/install to the pnpr server with the project's dependencies (and the existing lockfile, if any, for incremental resolution).
The server resolves against the client's registries, verifies the input lockfile under the client's policy, and answers with one gzipped JSON object carrying the resolved lockfile and stats.
Returns the resolved lockfile for use with pnpm's headless install, which fetches every tarball directly from the registries in parallel — like a normal install. See pnpm/pnpm#12230.

pnpr is a stateless resolver: it stores no tarballs and serves no file content.

Usage

This package is used internally by pnpm when the pnprServer config option is set. It is not intended to be called directly, but can be used programmatically:

import { fetchFromPnpmRegistry } from '@pnpm/pnpr.client'

const { lockfile, stats } = await fetchFromPnpmRegistry({
  registryUrl: 'http://localhost:4000',
  dependencies: { react: '^19.0.0' },
  devDependencies: { typescript: '^5.0.0' },
})

console.log(`Resolved ${stats.totalPackages} packages`)
// lockfile is ready for headless install

Configuration

Add to pnpm-workspace.yaml to enable automatically during pnpm install:

pnprServer: http://localhost:4000