@ohos-ports/nx 23.2.0-beta.0 → 23.2.1-beta.0

package/dist/src/utils/object-sort.js

@@ -1,9 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.sortObjectByKeys = sortObjectByKeys;
-function sortObjectByKeys(originalObject) {
-    const keys = Object.keys(originalObject).sort();
-    const sortedObject = {};
-    keys.forEach((key) => (sortedObject[key] = originalObject[key]));
-    return sortedObject;
-}

package/dist/src/utils/output.d.ts

@@ -1,232 +0,0 @@
-import { WriteStream } from 'tty';
-import type { TaskStatus } from '../tasks-runner/tasks-runner';
-/**
- * The statuses whose output can be collapsed to a single line: the task did the
- * work, or the cache stood in for it.
- */
-export type CollapsibleTaskStatus = Extract<TaskStatus, 'success' | 'local-cache' | 'local-cache-kept-existing' | 'remote-cache'>;
-/**
- * `static-failures-only` is `static` with successful tasks collapsed to a single
- * line. They select the same life cycle and differ only in what it prints, so
- * everywhere the life cycle is chosen, the TUI is ruled out, or output is
- * routed, the two behave identically.
- */
-export declare function isStaticOutputStyle(outputStyle: string | undefined): boolean;
-/**
- * Whether a run prints every task's output in full rather than collapsing the
- * ones that succeeded. Both static life cycles and the batch renderer have to
- * agree on this, so they read it from here rather than each deriving it.
- *
- * Exactly one style collapses, and it is also what a run that named no style
- * gets. Every other style prints in full because it was asked for explicitly,
- * so none may quietly withhold output. Note the static life cycles serve more
- * styles than the static-sounding ones: `shouldUseDynamicLifeCycle` bails on
- * `isCI()` before it looks at the style at all, so in CI `dynamic` and `tui`
- * land here too. This is written as a deny-list for that reason — a new style
- * prints in full until someone decides otherwise, rather than silently
- * collapsing because an allow-list did not list it.
- *
- * Resolving the absent case here rather than assigning `outputStyle` upstream is
- * deliberate: the value is also read by the orchestrator to decide whether a
- * task streams, and naming the default there stops `shouldStreamOutput` from
- * ever being consulted — including for the continuous tasks that must stream.
- */
-export declare function printsFullTaskOutput(args: {
-    verbose?: boolean;
-    outputStyle?: string;
-}): boolean;
-/**
- * Whether task output should be wrapped in collapsible log groups. Grouping
- * requires each task's output to be written as one contiguous block, which is
- * why batch mode's implicit streaming backs off when this is on. It does not
- * govern streaming in general — an explicit `--output-style`, the TUI, and
- * long running tasks all still stream.
- */
-export declare function isLogGroupingEnabled(): boolean;
-/**
- * Whether a batch task's output should be held back from the live stream and
- * rendered inside a fold instead. A batch worker writes to stdout/stderr live,
- * so forwarding that copy would put its bytes outside the group and defeat the
- * fold; what is held back is written to a file and rendered by the orchestrator.
- *
- * Note it is the captured file, not each task's `terminalOutput`, that makes
- * this lossless. A worker is free to write bytes it attributes to no task —
- * `@nx/maven`'s exit-code dump, `@nx/gradle`'s configuration phase — and those
- * appear in no `terminalOutput` at all, so the fold has to be able to fall back
- * to the file. See `TaskOrchestrator.printGroupedBatchOutput` for when it does.
- *
- * This is only worth doing when grouping is on and the user has not asked to
- * stream — an explicit stream style (which sets NX_STREAM_OUTPUT) wants the
- * live copy, folds or not.
- */
-export declare function shouldGroupBatchOutput(): boolean;
-export interface CLIErrorMessageConfig {
-    title: string;
-    bodyLines?: string[];
-    slug?: string;
-}
-export interface CLIWarnMessageConfig {
-    title: string;
-    bodyLines?: string[];
-    slug?: string;
-}
-export interface CLINoteMessageConfig {
-    title: string;
-    bodyLines?: string[];
-}
-export interface CLISuccessMessageConfig {
-    title: string;
-    bodyLines?: string[];
-}
-/**
- * Custom orange color using ANSI 256-color code 214.
- * picocolors does not support keyword-based colors like chalk,
- * so orange is implemented manually.
- */
-export declare function orange(text: string): string;
-declare class CLIOutput {
-    cliName: string;
-    formatCommand: (taskId: string) => string;
-    /**
-     * Longer dash character which forms more of a continuous line when place side to side
-     * with itself, unlike the standard dash character
-     */
-    private get VERTICAL_SEPARATOR();
-    /**
-     * Expose some color and other utility functions so that other parts of the codebase that need
-     * more fine-grained control of message bodies are still using a centralized
-     * implementation.
-     */
-    colors: {
-        gray: import("picocolors/types").Formatter;
-        green: import("picocolors/types").Formatter;
-        red: import("picocolors/types").Formatter;
-        cyan: import("picocolors/types").Formatter;
-        white: import("picocolors/types").Formatter;
-        orange: typeof orange;
-    };
-    bold: import("picocolors/types").Formatter;
-    underline: import("picocolors/types").Formatter;
-    dim: import("picocolors/types").Formatter;
-    /**
-     * Whether the terminal is positioned at the start of a line. Task output does
-     * not reliably end in a newline, so writers that must begin on a fresh line
-     * ask for one via {@link ensureLineStart} rather than guessing.
-     *
-     * Holding that true means a writer that can leave the cursor mid-line has to
-     * be routed through this class or declared to it. The ones that exist today:
-     *
-     * - This class's own writes, via {@link writeToStream}.
-     * - A batch worker's live output, via {@link writeTaskOutputChunk}.
-     * - `nx:run-commands`, which is the only executor that runs in the main
-     *   process (`task-orchestrator.ts` gates that on the executor name), and
-     *   whose raw writes go through {@link writeTaskOutputChunk} for this reason.
-     *   Its `addColorAndPrefix` splits on newlines without ever appending one, so
-     *   its chunks routinely end mid-line.
-     * - A pseudo-terminal task, which cannot be routed: the native side writes to
-     *   this process's stdout from Rust, at arbitrary PTY read boundaries. It
-     *   declares itself via {@link noteExternalWrite} instead, which is why that
-     *   exists.
-     *
-     * Two bypasses are deliberate and safe, both because they re-emit output a
-     * whole line at a time via `formatPrefixedLines`, which appends `EOL` to every
-     * line it writes: forked task streaming through
-     * `NodeChildProcessWithNonDirectOutput`'s `addPrefixTransformer`, and
-     * `writePrefixedLines` for a main-process `nx:run-commands` under
-     * `NX_PREFIX_OUTPUT`.
-     *
-     * One bypass is known and is NOT safe. With `NX_NATIVE_COMMAND_RUNNER=false`,
-     * `forkProcessLegacy` forks with inherited stdio and yields
-     * `NodeChildProcessWithDirectOutput`, whose child writes straight to this
-     * process's fd 1 at arbitrary boundaries — unroutable and undeclarable from
-     * here. Line tracking is simply wrong on that path; it degrades to the
-     * pre-tracking behavior of a glued marker rather than to anything new. Do not
-     * read this list as closed: it is what is known, and the way to tell you are
-     * adding to it is that you are writing to stdout during a run without going
-     * through {@link writeToStream}, {@link writeTaskOutputChunk} or
-     * {@link noteExternalWrite}.
-     */
-    private atLineStart;
-    private writeToStream;
-    /**
-     * Forwards a chunk of a task's output live, keeping {@link atLineStart}
-     * accurate. Batch workers write raw chunks that routinely end mid-line, and a
-     * collapsed summary line must not be glued onto one.
-     *
-     * @internal Not part of the output API plugins may rely on.
-     */
-    writeTaskOutputChunk(chunk: string | Buffer, stream?: WriteStream): void;
-    /**
-     * Declares output this class could not route — a pseudo-terminal task's, which
-     * the native side writes straight to our stdout — so the next writer needing a
-     * fresh line asks for one instead of trusting a stale position.
-     *
-     * The chunk is inspected rather than assumed mid-line, so output that did end
-     * on a line boundary does not cost a blank line. PTY chunks often end in an
-     * escape sequence after the newline, and that reads as mid-line, which is the
-     * safe direction to be wrong in: a spare newline, never a glued one.
-     */
-    noteExternalWrite(chunk?: string | Buffer): void;
-    private ensureLineStart;
-    overwriteLine(lineText?: string): void;
-    private writeOutputTitle;
-    private writeOptionalOutputBody;
-    applyNxPrefix(color: string, text: string): string;
-    addNewline(stream?: WriteStream): void;
-    addVerticalSeparator(color?: string): void;
-    addVerticalSeparatorWithoutNewLines(color?: string): void;
-    getVerticalSeparatorLines(color?: string): string[];
-    private getVerticalSeparator;
-    error({ title, slug, bodyLines }: CLIErrorMessageConfig): void;
-    warn({ title, slug, bodyLines }: CLIWarnMessageConfig): void;
-    note({ title, bodyLines }: CLINoteMessageConfig): void;
-    success({ title, bodyLines }: CLISuccessMessageConfig): void;
-    logSingleLine(message: string): void;
-    logRawLine(message: string): void;
-    logCommand(message: string, taskStatus?: TaskStatus): void;
-    logCommandOutput(message: string, taskStatus: TaskStatus, output: string): void;
-    /**
-     * A single line standing in for a task's full output, used when the output
-     * itself carries no information worth printing (a success, or a cache hit).
-     * Statuses that carry a diagnosable body are deliberately not accepted here.
-     */
-    logCommandSummary(message: string, taskStatus: CollapsibleTaskStatus): void;
-    /**
-     * A one-line stand-in for a task whose full output is shown elsewhere — used
-     * for the tasks of a batch rendered as a single log group rather than per
-     * task. `note` points the reader at that group.
-     */
-    logCommandRedirect(message: string, taskStatus: Exclude<TaskStatus, 'skipped'>, note: string): void;
-    /**
-     * Prints a batch's combined output as one log group. A batch runner's
-     * diagnostics — a crash, a config-phase error, a runner summary — belong to no
-     * single task, so the group is labelled with the batch rather than a task.
-     *
-     * The batch's own output is copied straight from the file it was captured
-     * into, so an arbitrarily long log costs a fixed amount of memory here.
-     * Nothing is withheld: this rendering is chosen because the whole log was
-     * asked for, because no task claimed any of it, or because a task failed or
-     * was stopped — in which case repeating claimed bytes beside the per-task
-     * blocks is deliberate (see TaskOrchestrator.printGroupedBatchOutput).
-     */
-    logBatchGroup(label: string, body: {
-        capturedOutputPath?: string;
-        trailer?: string;
-    }, taskStatus: TaskStatus): void;
-    /**
-     * Copies a file to stdout a chunk at a time. Reading it into one string would
-     * reintroduce the unbounded growth that writing it to disk avoided, and a
-     * long batch log can exceed the maximum length of a JS string.
-     */
-    private copyFileToStream;
-    private getCommandWithStatus;
-    private getStatusIcon;
-    private normalizeMessage;
-    private addTaskStatus;
-    log({ title, bodyLines, color }: CLIWarnMessageConfig & {
-        color?: string;
-    }): void;
-    drain(): Promise<void>;
-}
-export declare const output: CLIOutput;
-export {};