rman 2.11.2 → 2.11.3

package/builtins/platforms/node/services/publish.service.d.ts

@@ -136,10 +136,12 @@ export declare namespace PublishService {
      * landed on the registry first, and publishing is rare enough (once per release) that the
      * simplicity is worth more than the parallelism `run` gets from `power-tasks`.
      *
-     * If a package fails, every other still-pending entry depending on it (transitively) is marked
-     * `'error'` too and never attempted - publishing a package whose own new dependency range points
-     * at a version that never actually reached the registry would hand consumers a broken install.
-     * A package's own failure doesn't stop unrelated packages elsewhere in the plan, though.
+     * If a package fails, every other still-pending entry that **a consumer's install needs it for**
+     * (transitively) is marked `'error'` too and never attempted - publishing a package whose own new
+     * dependency range points at a version that never actually reached the registry would hand
+     * consumers a broken install. A package's own failure doesn't stop unrelated packages elsewhere in
+     * the plan, though, nor one that lists it only where an install does not need it (see
+     * `consumerNeeds`).
      */
     function applyPlan(repository: Repository, plan: Entry[], options?: ApplyOptions): Promise<Entry[]>;
 }

package/builtins/platforms/node/services/publish.service.js

@@ -259,10 +259,12 @@ export var PublishService;
      * landed on the registry first, and publishing is rare enough (once per release) that the
      * simplicity is worth more than the parallelism `run` gets from `power-tasks`.
      *
-     * If a package fails, every other still-pending entry depending on it (transitively) is marked
-     * `'error'` too and never attempted - publishing a package whose own new dependency range points
-     * at a version that never actually reached the registry would hand consumers a broken install.
-     * A package's own failure doesn't stop unrelated packages elsewhere in the plan, though.
+     * If a package fails, every other still-pending entry that **a consumer's install needs it for**
+     * (transitively) is marked `'error'` too and never attempted - publishing a package whose own new
+     * dependency range points at a version that never actually reached the registry would hand
+     * consumers a broken install. A package's own failure doesn't stop unrelated packages elsewhere in
+     * the plan, though, nor one that lists it only where an install does not need it (see
+     * `consumerNeeds`).
      */
     async function applyPlan(repository, plan, options = {}) {
         const packageManager = CiService.resolvePackageManager(repository, options.packageManager);
@@ -279,7 +281,7 @@ export var PublishService;
                 continue;
             }
             const pkg = entry.package;
-            const blocker = pkg.dependencies.find(d => failed.has(d.name));
+            const blocker = pkg.dependencies.find(d => failed.has(d.name) && consumerNeeds(pkg, d.name));
             if (blocker) {
                 failed.add(pkg.name);
                 result.push({ ...entry, status: 'error', reason: `dependency "${blocker.name}" failed to publish` });
@@ -343,6 +345,24 @@ function resolvePublishDir(pkg, contentsOverride) {
 function privateBySource(pkg) {
     return !!pkg.manifest.raw.private && !pkg.manifest.raw.publishConfig;
 }
+/** Whether a consumer installing `pkg` needs `name` to resolve: a `dependencies` entry, or a peer
+ *  not marked optional. */
+/* **Not every edge blocks a publish**, and blocking on all of them cost a release. A failed publish
+ * stops its dependents because their published range would point at a version that is not there -
+ * which is only true of what reaches the consumer:
+ * - `devDependencies` are removed from the published manifest (`derivePublishManifest`);
+ * - an optional peer that cannot be satisfied does not fail an install;
+ * - `optionalDependencies` are the ones npm proceeds without "if it cannot be found or fails to
+ *   install" (npm's own documentation; not measured here).
+ * Measured on opra's 1.31.0 release: `@opra/api-ui` failed its first publish, and `@opra/http` -
+ * which lists it as an optional peer and a devDependency only - was blocked, taking elastic, mongodb
+ * and sqb with it, though none of their installs would have needed api-ui. */
+function consumerNeeds(pkg, name) {
+    const raw = pkg.manifest.raw;
+    if (raw.dependencies?.[name] !== undefined)
+        return true;
+    return raw.peerDependencies?.[name] !== undefined && !raw.peerDependenciesMeta?.[name]?.optional;
+}
 /** Whether `pkg` is published from its own directory, whose `package.json` is then the manifest. */
 /* In place, `private` is the source's whatever `publishConfig` says - npm refuses to publish it. */
 function publishesInPlace(pkg, contentsOverride) {

package/constants.js

@@ -1 +1 @@
-export const version = '2.11.2';
+export const version = '2.11.3';

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "rman",
   "description": "Repository manager",
-  "version": "2.11.2",
+  "version": "2.11.3",
   "author": "Panates",
   "license": "MIT",
   "dependencies": {