@pnpm/pnpr 0.1.0-alpha.5 → 0.1.0-alpha.7

package/CHANGELOG.md

@@ -1,5 +1,35 @@
 # @pnpm/pnpr
 
+## 0.1.0-alpha.7
+
+### Minor Changes
+
+- Packument responses now carry a `Last-Modified` header derived from the document's `time.modified`, so a client's release-age check can learn the package-level last-publish bound from a cheap `HEAD` probe instead of downloading the metadata body.
+
+- A pnpr resolve request now carries the client's registries the way the `registries` setting declares them — keyed by URL, with the scopes routed to each, the bare-specifier prefix each answers to, and each one's `serverType` — in place of the prefix map it used to send.
+
+  The server routes them through the same inversion the config reader runs, so a pnpr-served install resolves a scoped dependency from the registry that scope is routed to, which it previously could not: only the default registry and the prefix-addressed ones reached the server. A declared `serverType` reaches it too, so the tarball URLs pnpr omits from the lockfile match the ones the client reconstructs.
+
+  Built-in scope routes the project has not pointed elsewhere are not declared, so a pnpr server's allowlist is not asked about `npm.jsr.io` on requests that resolve no JSR package.
+
+  A registry a request only declares is no longer refused up front for being off the server's allowlist — a client describes its whole configuration, including scopes a given resolve never reaches, so a stray `@scope:registry` in a developer's `~/.npmrc` no longer fails every install against a pnpr server that does not serve it. The boundary moves to the fetch itself: an origin the resolve does reach is refused before the request leaves the server, with the same message.
+
+  This changes the resolve and verify-lockfile request bodies. A pnpr server and its clients have to be on matching versions; the protocol is still experimental and unversioned.
+
+- A resolve request now carries the client's `resolutionMode`, so an install delegated to a pnpr server picks versions the way the client would. `time-based` and `lowest-direct` reached the server as nothing at all, leaving it on its `highest` default: the returned lockfile pinned the highest satisfying version of every dependency, and the setting appeared to be ignored.
+
+  This adds a field to the resolve request body. A server older than its client ignores it and keeps resolving `highest`; the protocol is still experimental and unversioned.
+
+### Patch Changes
+
+- Fixed `pnpm` installs using pnpr to honor the client's `autoInstallPeers`, `dedupePeers`, and `excludeLinksFromLockfile` settings [pnpm/pnpm#13389](https://github.com/pnpm/pnpm/issues/13389).
+
+## 0.1.0-alpha.6
+
+### Patch Changes
+
+- Validated forwarded catalog targets and kept catalog-specific resolutions isolated in the server cache.
+
 ## 0.1.0-alpha.5
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pnpm/pnpr",
-  "version": "0.1.0-alpha.5",
+  "version": "0.1.0-alpha.7",
   "description": "pnpm-compatible npm registry server, written in Rust",
   "keywords": [
     "pnpm",
@@ -28,14 +28,14 @@
     "LICENSE.md"
   ],
   "optionalDependencies": {
-    "@pnpm/pnpr.win32-x64": "0.1.0-alpha.5",
-    "@pnpm/pnpr.win32-arm64": "0.1.0-alpha.5",
-    "@pnpm/pnpr.darwin-x64": "0.1.0-alpha.5",
-    "@pnpm/pnpr.darwin-arm64": "0.1.0-alpha.5",
-    "@pnpm/pnpr.linux-x64": "0.1.0-alpha.5",
-    "@pnpm/pnpr.linux-arm64": "0.1.0-alpha.5",
-    "@pnpm/pnpr.linux-x64-musl": "0.1.0-alpha.5",
-    "@pnpm/pnpr.linux-arm64-musl": "0.1.0-alpha.5"
+    "@pnpm/pnpr.win32-x64": "0.1.0-alpha.7",
+    "@pnpm/pnpr.win32-arm64": "0.1.0-alpha.7",
+    "@pnpm/pnpr.darwin-x64": "0.1.0-alpha.7",
+    "@pnpm/pnpr.darwin-arm64": "0.1.0-alpha.7",
+    "@pnpm/pnpr.linux-x64": "0.1.0-alpha.7",
+    "@pnpm/pnpr.linux-arm64": "0.1.0-alpha.7",
+    "@pnpm/pnpr.linux-x64-musl": "0.1.0-alpha.7",
+    "@pnpm/pnpr.linux-arm64-musl": "0.1.0-alpha.7"
   },
   "scripts": {
     "preinstall": "node install.js"