rman 2.10.1 → 2.11.0

package/utils/run-bin.js

@@ -1,8 +1,8 @@
 import { spawn } from 'node:child_process';
 import colors from 'ansi-colors';
+import { LOG_LEVELS } from '../core/classes/logger.js';
 import { BinPath } from './bin-path.js';
 import { trackChild } from './child-tracker.js';
-import { LOG_LEVELS } from './logger.js';
 /**
  * Runs one of the repository's locally installed binaries, passing **argv as an array** - no shell.
  *
@@ -62,7 +62,9 @@ export async function runBin(bin, argv, options = {}) {
          * while a status region is live had it, which since 2.3.0 is every one of them. */
         env: BinPath.env({
             cwd,
-            env: region && atLeast('info') ? { FORCE_COLOR: '1', ...(options.env ?? process.env) } : options.env,
+            env: forceColor(region, options, atLeast('info'))
+                ? { FORCE_COLOR: '1', ...(options.env ?? process.env) }
+                : options.env,
             app: options.app,
         }),
         windowsHide: true,
@@ -71,31 +73,46 @@ export async function runBin(bin, argv, options = {}) {
      *  which meant a plugin command's child outlived a Ctrl-C. See `trackChild`. */
     trackChild(child);
     let output = '';
+    /**
+     * **Split into lines per stream, holding the unfinished tail until the rest arrives** - the way
+     * `exec` already does. A `data` event ends wherever the pipe's buffer did, not at a newline, so
+     * splitting each chunk on its own cut a line arriving in two pieces into two lines. Harmless while
+     * the only reader was a panel row showing the last line; wrong once a caller prints every line, as
+     * the panel-off `run` does, where it put a newline in the middle of whatever the child wrote.
+     */
+    const pending = { stdout: '', stderr: '' };
+    const emit = (stream, text, flush) => {
+        const lines = (pending[stream] + text).split(/\r?\n/);
+        pending[stream] = flush ? '' : lines.pop();
+        for (const line of lines)
+            if (line)
+                options.onLine(line, stream);
+    };
     /** **Streamed through the region as it arrives, not held to the end.** Piping is how the region
      *  stays intact; buffering would additionally make a long command look silent, which is the very
      *  thing the region exists to fix. Only when a region is live - otherwise `pipe` keeps meaning
      *  "capture, and surface it if this fails". */
-    const collect = (d) => {
+    const collect = (stream) => (d) => {
         const text = d.toString();
         output += text;
         /** A caller taking the lines owns them - it is showing them somewhere of its own, and writing
          *  them here as well would both double them and scroll whatever it is drawing. */
-        if (options.onLine) {
-            for (const line of text.split(/\r?\n/))
-                if (line)
-                    options.onLine(line);
-            return;
-        }
+        if (options.onLine)
+            return emit(stream, text, false);
         if (region && atLeast('info'))
             region.passThrough(text);
     };
-    child.stdout?.on('data', collect);
-    child.stderr?.on('data', collect);
+    child.stdout?.on('data', collect('stdout'));
+    child.stderr?.on('data', collect('stderr'));
     return new Promise((resolve, reject) => {
         child.on('error', (e) => {
             reject(e?.code === 'ENOENT' ? new Error(`"${bin}" was not found - is it installed in this repository?`) : e);
         });
         child.on('close', code => {
+            /** A last line with no newline after it is still a line. */
+            if (options.onLine)
+                for (const stream of ['stdout', 'stderr'])
+                    emit(stream, '', true);
             if (code === 0)
                 return resolve({ code: 0, output });
             /** Captured output has to be surfaced here or it is lost with the process - the one thing
@@ -111,3 +128,32 @@ export async function runBin(bin, argv, options = {}) {
         });
     });
 }
+/**
+ * Whether a piped child is told it may colour anyway.
+ *
+ * A child checks `isTTY` to decide whether to colour, and a pipe is not one - so a child whose output
+ * is shown rather than read loses the colour it had with the terminal. Two cases show it: a live
+ * region routing it through `passThrough`, and a caller taking the lines to print (`onLine`) while
+ * our own output really is a terminal. Not when stdout is redirected, where escapes would land in a
+ * file, and not under `NO_COLOR`, which is the user saying no.
+ *
+ * **`FORCE_COLOR` turns on colour and nothing else.** A tool's live output - a spinner, a progress
+ * bar - is gated on `isTTY`, which stays false, so a child piped this way prints plain lines in
+ * colour: exactly what a run with no progress panel is after.
+ */
+function forceColor(region, options, info) {
+    if (!info)
+        return false;
+    if (region)
+        return true;
+    return !!options.onLine && colorsPrintedOutput();
+}
+/**
+ * Whether a child whose lines rman prints itself should be told to colour them: our own stdout is a
+ * terminal, and `NO_COLOR` is not set. The one rule for both kinds of step - `runBin`'s, above, and a
+ * shell step `exec` runs with its lines printed by `RunService` - so the two cannot disagree about
+ * when a piped child gets its colour back.
+ */
+export function colorsPrintedOutput() {
+    return !!process.stdout.isTTY && !process.env.NO_COLOR;
+}

package/utils/version-group.d.ts

@@ -26,6 +26,15 @@ export declare function groupKeyOf(pkg: Package): string;
  * opted out of grouping has no group to name.
  */
 export declare function isSoloGroupKey(key: string): boolean;
+/** Whether a group key is one the repository **named** (`group: "core"`) - a real value, as opposed
+ *  to the implicit default group or the root's own entry, which have descriptions rather than names. */
+export declare function isNamedGroupKey(key: string): boolean;
+/**
+ * The group key of a monorepo root's own plan entry. Not something `groupKeyOf` ever returns: the
+ * root is never a member of a release group - its number is the repository's identity - so the
+ * planner gives it a key of its own, and this is that key's one spelling.
+ */
+export declare const ROOT_GROUP_KEY = "__root__";
 /**
  * How many distinct version lines this package's repository releases along - 1 when every package
  * moves together, more once anything is grouped apart.

package/utils/version-group.js

@@ -34,6 +34,17 @@ export function groupKeyOf(pkg) {
 export function isSoloGroupKey(key) {
     return key.startsWith('solo:');
 }
+/** Whether a group key is one the repository **named** (`group: "core"`) - a real value, as opposed
+ *  to the implicit default group or the root's own entry, which have descriptions rather than names. */
+export function isNamedGroupKey(key) {
+    return key.startsWith('named:');
+}
+/**
+ * The group key of a monorepo root's own plan entry. Not something `groupKeyOf` ever returns: the
+ * root is never a member of a release group - its number is the repository's identity - so the
+ * planner gives it a key of its own, and this is that key's one spelling.
+ */
+export const ROOT_GROUP_KEY = '__root__';
 /**
  * How many distinct version lines this package's repository releases along - 1 when every package
  * moves together, more once anything is grouped apart.