rman 2.0.0-beta.5 → 2.0.1

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

@@ -156,7 +156,13 @@ export var PublishService;
         const packages = filterPackages(repository.getPackages({ toposort: true }), options);
         const dirtyFiles = await git.listDirtyFiles({ absolute: true });
         const isDirty = (pkg) => dirtyFiles.some(f => !path.relative(pkg.dirname, f).startsWith('..'));
-        const viewPackage = deps.npmViewPackage ?? ((name, cwd) => npmViewPackage(name, cwd, options));
+        /** Per package, not per run: `resolveRegistry` reads the package's own `publishConfig.registry`
+         *  when `--registry` was not given, so the question is asked where the answer lives. The test
+         *  seam keeps its `(name, cwd)` shape - a stub answers from a map and has no registry to
+         *  respect. */
+        const viewPackage = (pkg) => deps.npmViewPackage
+            ? deps.npmViewPackage(pkg.name, pkg.dirname)
+            : npmViewPackage(pkg.name, pkg.dirname, { ...options, registry: resolveRegistry(pkg, options.registry) });
         const entries = new Map();
         const toCheck = [];
         for (const pkg of packages) {
@@ -200,7 +206,7 @@ export var PublishService;
             }
         }
         await Promise.all(toCheck.map(async (pkg) => {
-            const view = await viewPackage(pkg.name, pkg.dirname);
+            const view = await viewPackage(pkg);
             const registryVersion = view?.latest;
             /** **This version**, not `latest` - the two part company the moment a prerelease is
              *  published under its own dist-tag, and `latest` then never moves however many betas go
@@ -304,6 +310,40 @@ function resolvePublishDir(pkg, contentsOverride) {
     const rel = (typeof native === 'string' && native) || configured || contentsOverride;
     return rel ? path.resolve(pkg.dirname, rel) : pkg.dirname;
 }
+/**
+ * Which registry a package's own version is asked about, and published to.
+ *
+ * npm's own precedence, measured rather than assumed: `--registry` on the command line wins over
+ * `package.json`'s `publishConfig.registry`, and with neither given npm resolves it itself from
+ * `.npmrc` - including a scoped `@owner:registry=`, which is how a GitHub Packages repository is
+ * normally set up.
+ *
+ * @returns the registry to pass, or `undefined` to let npm decide.
+ */
+/* **The check has to ask the registry the publish will use, and it did not.** `npm publish` honours
+ * `publishConfig.registry` - it survives into the generated manifest, since `derivePublishManifest`
+ * deletes only `publishConfig.directory` - but **`npm view` ignores it**: measured, a package whose
+ * `publishConfig.registry` pointed at a dead local address was still answered from
+ * registry.npmjs.org.
+ *
+ * So question B was asked of the wrong registry for exactly one of the three ways a registry can be
+ * stated, and `npmViewPackage` swallows a failed lookup as `undefined`, which reads as "never
+ * published". Two consequences, and the second is the one to fear:
+ *
+ * - the plan proposes a publish on **every** run, so the first succeeds and the second is rejected
+ *   by the registry for republishing a version - a release job that fails for no reason of its own;
+ * - if some *other* package holds that name on npmjs.org, rman reads a stranger's version list, and
+ *   can report `up-to-date` for a publish that never happened.
+ *
+ * A scoped name in an `.npmrc` was always fine - measured, `npm view @foo/bar` with
+ * `@foo:registry=http://127.0.0.1:1/` tries that address - which is why this went unnoticed.
+ *
+ * Returning `undefined` rather than a default is the half that keeps it working: passing an explicit
+ * `--registry` would override whatever `.npmrc` says and break the case that already worked. */
+function resolveRegistry(pkg, override) {
+    const native = pkg.manifest.raw.publishConfig?.registry;
+    return override || (typeof native === 'string' && native ? native : undefined);
+}
 /**
  * The retired `publish.directory` spelling, if a config still carries it.
  *

package/builtins/publish-targets/npm/npm-publish-target.js

@@ -59,7 +59,8 @@ export class NpmPublishTarget {
         },
         registry: {
             target: 'cli',
-            describe: 'Registry to check against and publish to (default: whatever .npmrc already configures)',
+            describe: 'Registry to check against and publish to, for every package in this run. Overrides each ' +
+                'package\'s own "publishConfig.registry"; with neither, npm resolves .npmrc itself',
             type: 'string',
         },
         userconfig: {

package/constants.js

@@ -1 +1 @@
-export const version = '2.0.0-beta.5';
+export const version = '2.0.1';

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "rman",
   "description": "Repository manager",
-  "version": "2.0.0-beta.5",
+  "version": "2.0.1",
   "author": "Panates",
   "license": "MIT",
   "dependencies": {

package/utils/progress-panel.js

@@ -128,8 +128,22 @@ export class ProgressPanel {
                 failedCount++;
                 if (this.live.enabled) {
                     console.log(colors.red.bold('X'), item.name, duration);
+                    /* **The replayed log is printed as it was captured, never painted.** It holds the output
+                     * of every step this item ran, and only the last one failed - so colouring the block red
+                     * reports the ones that succeeded as failures. Measured on a real build whose `before`
+                     * ran `rman check` and then `rman lint`: check passed and printed
+                     * `✅ no circular dependency was found` and `1 succeeded, 0 failed`, and both came back
+                     * red under the failing package.
+                     *
+                     * It also corrupts what the steps themselves coloured. `colors.red()` wraps the whole
+                     * string, so a line with its own colour keeps it up to its reset and then falls into red
+                     * for the remainder: `1 succeeded, 0 failed` rendered with `1 succeeded` still green and
+                     * the comma after it red.
+                     *
+                     * The `X` above already says the item failed, and the step that failed printed its own
+                     * error. */
                     if (item.log.length)
-                        console.log(colors.red(item.log.join('\n')));
+                        console.log(item.log.join('\n'));
                 }
             }
             else {