rman 1.3.0 → 2.0.0-beta.3

package/utils/branch-guard.js

@@ -1,6 +1,37 @@
 import colors from 'ansi-colors';
 import micromatch from 'micromatch';
 import { GitHelper } from './git.js';
+/**
+ * `--allow-branch`/`--ignore-branch` as a declaration, to spread into a command's `config` block.
+ * See `packageFilterOptions` for why this is `satisfies` rather than an annotation.
+ *
+ * **The key is the camelCase one and `cliName` carries the flag's spelling.** `allowBranch` is what
+ * a `.rmanrc` writes and what `assertAllowedBranch` reads off the config; `--allow-branch` is what
+ * the shell sees. The `Argv` version relied on yargs converting one into the other silently, which
+ * is why `applyBranchGuardOptions` declares `'allow-branch'` and `readBranchGuardOptions` reads
+ * `args.allowBranch`.
+ *
+ * **`target: 'cli'`, even though `allowBranch` *is* a config key.** It is a repo-wide core key read
+ * off the root, not any command's - so it belongs on `RmanConfig` directly, and a command that
+ * reads it names it in `configKeys`. Declaring it `'both'` here would contribute `version.allowBranch`,
+ * which nothing reads.
+ */
+export const branchGuardOptions = {
+    allowBranch: {
+        target: 'cli',
+        cliName: 'allow-branch',
+        describe: 'Refuse to run unless the current branch matches this glob (repeatable) - default: .rmanrc ' +
+            '"allowBranch", or no restriction at all',
+        type: 'string',
+    },
+    ignoreBranch: {
+        target: 'cli',
+        cliName: 'ignore-branch',
+        describe: 'Refuse to run if the current branch matches this glob (repeatable) - default: .rmanrc ' +
+            '"ignoreBranch", or no restriction at all',
+        type: 'string',
+    },
+};
 /** `--allow-branch`/`--ignore-branch`, the same shape and describe text in every command that
  *  supports them - mirrors `package-filter.ts`'s own `applyPackageFilterOptions`. */
 export function applyBranchGuardOptions(cmd) {

package/utils/color-yaml.d.ts

@@ -0,0 +1,8 @@
+/**
+ * A YAML document with syntax colour, for the two commands that print one to be **looked at** -
+ * `rman config` and `--config`.
+ *
+ * **Only call this when `process.stdout.isTTY`.** Colouring a document that is being redirected
+ * makes it unloadable, which is the whole reason the callers gate on a terminal.
+ */
+export declare function colorYaml(text: string): string;

package/utils/color-yaml.js

@@ -0,0 +1,86 @@
+import colors from 'ansi-colors';
+/**
+ * A YAML document with syntax colour, for the two commands that print one to be **looked at** -
+ * `rman config` and `--config`.
+ *
+ * **Only call this when `process.stdout.isTTY`.** Colouring a document that is being redirected
+ * makes it unloadable, which is the whole reason the callers gate on a terminal.
+ */
+/* **Line-based and deliberately shallow.** This is a highlighter, not a parser: it colours what a
+ * reader's eye uses to navigate - the key, the list marker, a literal - and leaves anything it is
+ * not sure about alone. A real parse would have to round-trip js-yaml's own output to gain nothing
+ * a reader would notice, and every extra rule is a new way to mangle a value.
+ *
+ * **What it colours and why that set**:
+ *
+ * - the **key**, in cyan, because that is what you scan a config for;
+ * - **`${{ ... }}`**, in magenta, because rman's configs are full of them and because a `version`
+ *   hook is printed *raw* (`DEFERRED_PATHS`) - the one place an unresolved expression is correct
+ *   rather than a bug, and the colour is what stops it reading as a mistake;
+ * - **numbers, booleans and `null`**, in yellow, since `skip: false` and `skip: "false"` mean
+ *   different things and nothing else in the output tells them apart;
+ * - **`[Function: name]`**, in grey, because it is this printer's placeholder rather than anything
+ *   the config says - the one value in the output that is not a value;
+ * - the **`-`** of a list item and a `#` comment, in grey, as structure rather than content.
+ *
+ * A plain string value is left uncoloured on purpose. It is the *content*, usually the longest
+ * thing on the line, and colouring it competes with the key for attention - which is the failure
+ * mode of a highlighter that paints everything.
+ *
+ * **The two places a shallow pass has to be careful, and neither is hypothetical:**
+ *
+ * - **A `:` inside a value.** js-yaml quotes any scalar holding one, so the line is
+ *   `key: 'a: b'` - and the key pattern stops at the *first* colon, which is the right one. Nothing
+ *   to do, but it is why the pattern is written `[^:]*` rather than anything greedier.
+ * - **A folded block scalar.** `lineWidth: 100` makes js-yaml emit `describe: >-` and continue on
+ *   deeper-indented lines, and a continuation line is prose: one holding `(default: ...)` would
+ *   otherwise have half a sentence coloured as a key. So the block's indent is tracked and its
+ *   content is left alone but for expressions. A `#` there is prose too, not a comment. */
+export function colorYaml(text) {
+    /** The indent of the key that opened a block scalar, while one is open. Anything indented past it
+     *  is that block's content; the first line that is not ends it. */
+    let blockIndent;
+    return text
+        .split('\n')
+        .map(line => {
+        const indent = line.length - line.trimStart().length;
+        if (blockIndent !== undefined) {
+            if (line.trim() === '' || indent > blockIndent)
+                return colorExpressions(line);
+            blockIndent = undefined;
+        }
+        if (BLOCK_SCALAR.test(line))
+            blockIndent = indent;
+        return colorLine(line);
+    })
+        .join('\n');
+}
+/** `key: >-`, `key: |`, `key: >2-`, and the bare `- >-` of a list item. */
+const BLOCK_SCALAR = /:\s*[|>][0-9]*[-+]?\s*$/;
+const EXPRESSION = /\$\{\{[\s\S]*?\}\}/g;
+const LITERAL = /^(true|false|null|~|-?\d+(?:\.\d+)?)$/;
+const FUNCTION = /^"?\[Function(?::[^\]]*)?\]"?$/;
+function colorLine(line) {
+    const comment = /^(\s*)#(.*)$/.exec(line);
+    if (comment)
+        return comment[1] + colors.gray(`#${comment[2]}`);
+    /** `indent`, an optional `- ` for a list item, then either `key:` plus a value or a bare item. */
+    const parsed = /^(\s*)(- )?(?:([^\s:][^:]*):(\s|$))?([\s\S]*)$/.exec(line);
+    if (!parsed)
+        return line;
+    const [, indent = '', dash, key, gap = '', rest = ''] = parsed;
+    return indent + (dash ? colors.gray(dash) : '') + (key ? `${colors.cyan(key)}:${gap}` : '') + colorValue(rest);
+}
+function colorValue(value) {
+    const trimmed = value.trim();
+    if (!trimmed)
+        return value;
+    if (LITERAL.test(trimmed))
+        return value.replace(trimmed, colors.yellow(trimmed));
+    if (FUNCTION.test(trimmed))
+        return value.replace(trimmed, colors.gray(trimmed));
+    return colorExpressions(value);
+}
+function colorExpressions(value) {
+    return value.replace(EXPRESSION, match => colors.magenta(match));
+}

package/utils/exec.d.ts

@@ -1,4 +1,14 @@
+import type { RmanApplication } from '../core/application.js';
 export interface ExecOptions {
+    /**
+     * The application whose technologies put a repository's locally installed binaries on PATH -
+     * `node_modules/.bin` for a Node repository, whatever another technology uses.
+     *
+     * Passed rather than looked up, so a command run against one repository can never pick up the
+     * binaries of another in the same process. Omitted (a caller outside any repository) leaves the
+     * inherited PATH exactly as it was, which is also what a repository naming no plugin gets.
+     */
+    app?: RmanApplication;
     /** 'inherit' streams the child directly to our stdio (used for non-TTY/CI passthrough).
      *  'pipe' (default) captures output so the caller can drive a live view via onLine. */
     stdio?: 'inherit' | 'pipe';

package/utils/exec.js

@@ -17,7 +17,7 @@ export async function exec(command, options) {
         ...options,
     };
     opts.env = {
-        ...BinPath.env({ cwd: opts.cwd }),
+        ...BinPath.env({ cwd: opts.cwd, app: opts.app }),
         ...opts.env,
     };
     opts.cwd = opts.cwd || process.cwd();

package/utils/git.d.ts

@@ -46,6 +46,19 @@ export declare class GitHelper {
     /** Tag names matching the glob `pattern` (e.g. `"v*"`, `"pkg-a@*"`), newest version first. */
     listTags(pattern: string): Promise<string[]>;
     /** Whether `tag` exists as an exact git tag name (not a glob - a literal ref check). */
+    /**
+     * Every tag matching `pattern`, paired with the **commit** it points at - newest version first,
+     * the same order `listTags` returns.
+     *
+     * `%(*objectname)` is the dereferenced target and is empty for a lightweight tag, so the commit
+     * is that or `%(objectname)`. rman's own tags are lightweight; a repository's existing ones may
+     * not be, and an annotated tag's `objectname` is the *tag object*, which matches no commit and
+     * would make the tag silently invisible to anything comparing shas.
+     */
+    listTagCommits(pattern: string): Promise<{
+        tag: string;
+        sha: string;
+    }[]>;
     tagExists(tag: string): Promise<boolean>;
     /** The most recent commit that changed `file` (tracked history only) - `undefined` if it has
      *  never been committed. Answers "since when has this file last been updated", independent of
@@ -61,6 +74,19 @@ export declare class GitHelper {
     /** The repository's very first commit (the oldest root commit, for a history with several) -
      *  `undefined` for a repository with no commits at all. The "since the beginning" boundary for
      *  a package being released for the first time, with no earlier tag to measure from. */
+    /** HEAD's own sha, or `undefined` in a repository with no commits yet (or none at all) - the
+     *  same "answer nothing rather than throw" shape `rootCommit` and `describeTag` take, because
+     *  every caller here already has a "nothing to go on" branch. */
+    /** The date a ref points at, as `YYYY-MM-DD`. The **committer** date, not the author's: a
+     *  rebased or cherry-picked release commit was authored earlier than it shipped, and what a
+     *  changelog heading states is when the release happened. `undefined` for a ref that resolves to
+     *  nothing. */
+    commitDate(ref: string): Promise<string | undefined>;
+    /** The commit `ref` names - a sha, a tag, a branch - or `undefined` when git does not recognize
+     *  it. `^{commit}` so an annotated tag answers with the commit rather than the tag object, and
+     *  so a tree or blob answers with nothing rather than a sha that matches no commit. */
+    resolveCommit(ref: string): Promise<string | undefined>;
+    headSha(): Promise<string | undefined>;
     rootCommit(): Promise<string | undefined>;
     /**
      * Stages and commits exactly `files` (relative to `cwd`, or absolute) with `message` - never a

package/utils/git.js

@@ -148,6 +148,32 @@ export class GitHelper {
         }
     }
     /** Whether `tag` exists as an exact git tag name (not a glob - a literal ref check). */
+    /**
+     * Every tag matching `pattern`, paired with the **commit** it points at - newest version first,
+     * the same order `listTags` returns.
+     *
+     * `%(*objectname)` is the dereferenced target and is empty for a lightweight tag, so the commit
+     * is that or `%(objectname)`. rman's own tags are lightweight; a repository's existing ones may
+     * not be, and an annotated tag's `objectname` is the *tag object*, which matches no commit and
+     * would make the tag silently invisible to anything comparing shas.
+     */
+    async listTagCommits(pattern) {
+        try {
+            const { stdout } = await execFileAsync('git', ['tag', '--list', pattern, '--sort=-v:refname', '--format=%(refname:short)%09%(objectname)%09%(*objectname)'], { cwd: this.cwd });
+            return stdout
+                .trim()
+                .split(/\r?\n/)
+                .filter(Boolean)
+                .map(line => {
+                const [tag, objectname, deref] = line.split('\t');
+                return { tag, sha: deref || objectname };
+            })
+                .filter(t => t.tag && t.sha);
+        }
+        catch {
+            return [];
+        }
+    }
     async tagExists(tag) {
         try {
             await execFileAsync('git', ['rev-parse', '--verify', '--quiet', `refs/tags/${tag}`], { cwd: this.cwd });
@@ -197,6 +223,45 @@ export class GitHelper {
     /** The repository's very first commit (the oldest root commit, for a history with several) -
      *  `undefined` for a repository with no commits at all. The "since the beginning" boundary for
      *  a package being released for the first time, with no earlier tag to measure from. */
+    /** HEAD's own sha, or `undefined` in a repository with no commits yet (or none at all) - the
+     *  same "answer nothing rather than throw" shape `rootCommit` and `describeTag` take, because
+     *  every caller here already has a "nothing to go on" branch. */
+    /** The date a ref points at, as `YYYY-MM-DD`. The **committer** date, not the author's: a
+     *  rebased or cherry-picked release commit was authored earlier than it shipped, and what a
+     *  changelog heading states is when the release happened. `undefined` for a ref that resolves to
+     *  nothing. */
+    async commitDate(ref) {
+        try {
+            const { stdout } = await execFileAsync('git', ['log', '-1', '--format=%cI', ref], { cwd: this.cwd });
+            return stdout.trim().slice(0, 10) || undefined;
+        }
+        catch {
+            return undefined;
+        }
+    }
+    /** The commit `ref` names - a sha, a tag, a branch - or `undefined` when git does not recognize
+     *  it. `^{commit}` so an annotated tag answers with the commit rather than the tag object, and
+     *  so a tree or blob answers with nothing rather than a sha that matches no commit. */
+    async resolveCommit(ref) {
+        try {
+            const { stdout } = await execFileAsync('git', ['rev-parse', '--verify', '--quiet', `${ref}^{commit}`], {
+                cwd: this.cwd,
+            });
+            return stdout.trim() || undefined;
+        }
+        catch {
+            return undefined;
+        }
+    }
+    async headSha() {
+        try {
+            const { stdout } = await execFileAsync('git', ['rev-parse', 'HEAD'], { cwd: this.cwd });
+            return stdout.trim() || undefined;
+        }
+        catch {
+            return undefined;
+        }
+    }
     async rootCommit() {
         try {
             const { stdout } = await execFileAsync('git', ['rev-list', '--max-parents=0', 'HEAD'], { cwd: this.cwd });

package/utils/logger.d.ts

@@ -1,10 +1,10 @@
-import type { Repository } from '../core/repository.js';
+import type { Repository } from '../core/classes/repository.js';
 export type LogLevel = 'silent' | 'error' | 'info' | 'verbose';
 export declare const LOG_LEVELS: LogLevel[];
 /**
  * Gates console output by verbosity (`--log-level`/`.rmanrc logLevel`) so a command's routine
  * narration can be turned down without losing failure output - the same semantics `run`'s own
- * classic per-step log already used (see `resolveLogLevel` in `commands/run.ts`), centralized here
+ * classic per-step log already used (see `resolveLogLevel` in `commands/run.command.ts`), centralized here
  * so every command can respect `--log-level` instead of reimplementing the checks, or ignoring it
  * altogether via plain `console.log`.
  */

package/utils/logger.js

@@ -2,7 +2,7 @@ export const LOG_LEVELS = ['silent', 'error', 'info', 'verbose'];
 /**
  * Gates console output by verbosity (`--log-level`/`.rmanrc logLevel`) so a command's routine
  * narration can be turned down without losing failure output - the same semantics `run`'s own
- * classic per-step log already used (see `resolveLogLevel` in `commands/run.ts`), centralized here
+ * classic per-step log already used (see `resolveLogLevel` in `commands/run.command.ts`), centralized here
  * so every command can respect `--log-level` instead of reimplementing the checks, or ignoring it
  * altogether via plain `console.log`.
  */

package/utils/package-filter.d.ts

@@ -1,15 +1,41 @@
 import type { Argv } from 'yargs';
-import type { Package } from '../core/package.js';
+import type { Package } from '../core/classes/package.js';
 /** Shared by every command that iterates packages (`run`/`build`/`test`/`exec`, `list`, `ci`,
  *  `clean`, `version`, `publish`, `changelog`) - narrows *which* packages a command applies to,
  *  independent of what the command actually does to them. The repository's own standing filter,
  *  `.rmanrc "skip"`, is applied by `filterPackages` itself rather than being an option here: it is
  *  the repository's statement, not the caller's. */
 export interface PackageFilterOptions {
-    /** Only include packages whose name matches at least one of these globs (e.g. `@scope/*`). */
+    /**
+     * The technologies the **command itself** is for - `clean` and `ci` are npm's alone. Absent means
+     * every platform, which is what a command that speaks for no one in particular says.
+     *
+     * Declared as `CommandMetadata.platforms` and carried here; a repository never writes it.
+     */
+    commandPlatforms?: string[];
+    /** Only include packages whose name matches at least one of these globs (e.g. `@scope/*`), or
+     *  **`"/"`** for the repository's own root package - see `ROOT_SELECTOR`. */
     scope?: string | string[];
-    /** Exclude packages whose name matches at least one of these globs - applied after `scope`. */
+    /** Exclude packages whose name matches at least one of these globs (or `"/"`) - applied after
+     *  `scope`. */
     ignore?: string | string[];
+    /**
+     * Only include packages belonging to one of these **platforms** (`Package.provider`) - `['node']`,
+     * or `'node,cargo'` as one comma-separated value.
+     *
+     * **Which technology a package belongs to only became a per-package question when the walk
+     * started finding nested packages of another platform**, and this is the filter that question
+     * needs: in a polyglot repository `rman run build --platform node` is the whole npm half of it,
+     * and there was no way to say that. Where every package is one technology it selects everything
+     * or nothing, which is the honest answer rather than a flag that does nothing.
+     *
+     * **Names, not globs.** A platform's name is a short identifier a plugin chose (`'node'`), so the
+     * set of valid values is known and finite - which is also why a name that no package in the
+     * repository belongs to is an **error** listing the ones that are there, the same call
+     * `publish --target` makes. A glob would put this back to guessing, and a typo back to a silent
+     * empty result.
+     */
+    platform?: string | string[];
     /** Also include every package the matched set depends on (transitively) - e.g. to build
      *  everything a scoped app actually needs. */
     deps?: boolean;
@@ -17,6 +43,99 @@ export interface PackageFilterOptions {
      *  everything that could be affected by a scoped library's change. */
     dependents?: boolean;
 }
+/**
+ * **`--scope /` is the repository's own root package**, the one selector that is not a glob.
+ *
+ * The same `/` `.rmanrc`'s `"[/]"` block uses, and for the same reason stated there: *the root is
+ * never selected by name.* A glob matches package names, and a name can be anything - so
+ * `--scope rman-repo` happened to work (measured) while being exactly the name-based addressing the
+ * config selectors were redesigned to remove. `/` is structural, cannot collide with a package
+ * (nothing can be named it), and gives "the root" one spelling across config and CLI.
+ *
+ * Accepted by `--ignore` too. The asymmetry would be the thing to remember, and `--ignore /` -
+ * every package but the root - is a real thing to want of `clean`.
+ *
+ * **It selects nothing on a command whose candidates exclude the root**, which is most of them:
+ * `repository.packages` holds the workspace members only, so `rman list --scope /` and
+ * `rman run build --scope /` match nothing and say so. That is the honest answer rather than a
+ * special case - the root has no `list` row and contributes only `pre`/`post` bookends to `run`.
+ * `clean` and `changelog`, which put the root in their candidate list on purpose, are where it bites.
+ */
+export declare const ROOT_SELECTOR = "/";
+/**
+ * `--scope`/`--ignore`/`--deps`/`--dependents` as a **declaration** rather than a builder call -
+ * spread into a command's `config` block:
+ *
+ * ```ts
+ * config: { ...packageFilterOptions, ...branchGuardOptions, changelog: { ... } }
+ * ```
+ *
+ * **`satisfies`, never a `: Record<...>` annotation.** An annotation widens `type: 'string'` back to
+ * `string`, and every type derived from the declaration - the config contribution, the option's own
+ * value type - collapses with it. `satisfies` checks the shape and keeps the literals, and it also
+ * catches a misspelled key *here*, at the group's own line, rather than in the ten commands that
+ * spread it. The `Argv` chaining this replaces could not: a typo there was simply a new option.
+ *
+ * **Every option is `target: 'cli'`, including the ones that have a config twin.** A shared group
+ * belongs to no command, so declaring one `'both'` would contribute `version.scope` - a key nothing
+ * reads. Where a `.rmanrc` equivalent exists it is a core key in its own right (`allowBranch`), and
+ * a command that reads it names it in `configKeys`.
+ */
+export declare const packageFilterOptions: {
+    scope: {
+        target: "cli";
+        describe: string;
+        type: "string";
+    };
+    ignore: {
+        target: "cli";
+        describe: string;
+        type: "string";
+    };
+    platform: {
+        target: "cli";
+        describe: string;
+        type: "string";
+    };
+    deps: {
+        target: "cli";
+        describe: string;
+        type: "boolean";
+    };
+    dependents: {
+        target: "cli";
+        describe: string;
+        type: "boolean";
+    };
+};
+/**
+ * `--from-root`/`-r` - a group of one, and a function because its text is the command's own word
+ * for what it does. Spread it like the others: `...fromRootOption('Build')`.
+ *
+ * Only where a command scopes by the current directory; see `applyFromRootOption` for why adding it
+ * elsewhere is worse than leaving it out.
+ *
+ * **It was `--root` through 1.x, and the name said the opposite of what it does.** Every reader
+ * spells it the same single line - `options.fromRoot ? undefined : repository.currentPackage` - so
+ * the flag means *ignore where I am standing*, i.e. the **whole repository**. `--root` reads as "the
+ * root alone", which is the narrowest possible set rather than the widest, and the confusion was
+ * about to become a contradiction: a `--root-only` beside a `--root` that meant "everything" is
+ * unreadable.
+ *
+ * **`-r` is kept, and a two-letter `-fr` is not possible.** yargs' `short-option-groups` is on by
+ * default, so `-fr` parses as `-f -r` and `.strict()` answers `Unknown arguments: f, r` (measured).
+ * Turning that off makes `-fr` work and breaks every grouped short - `rman list -sj` works today.
+ * So the long name carries the meaning and the incumbent short stays.
+ */
+export declare function fromRootOption(verb: string): {
+    fromRoot: {
+        target: "cli";
+        cliName: string;
+        alias: string;
+        describe: string;
+        type: "boolean";
+    };
+};
 /** `--scope`/`--ignore`/`--deps`/`--dependents`, the same shape and describe text in every command
  *  that supports them - mirrors `run.command.ts`'s own `applyRunOptions`. */
 export declare function applyPackageFilterOptions<T>(cmd: Argv<T>): Argv<T>;
@@ -24,7 +143,8 @@ export declare function readPackageFilterOptions(args: any): PackageFilterOption
 /**
  * Narrows `packages` (the full, already-resolved list - toposort order, if any, is preserved)
  * down to what `options` selects. `scope`/`ignore` match against each package's bare name (glob
- * syntax via `micromatch` - `*`, `**`, `{a,b}`, ...); `ignore` is applied after `scope`, on
+ * syntax via `micromatch` - `*`, `**`, `{a,b}`, ...), plus `ROOT_SELECTOR` (`"/"`) for the root
+ * package, which is matched structurally rather than by name; `ignore` is applied after `scope`, on
  * whatever it left. `deps`/`dependents` then each independently expand *that* matched set along
  * `Package.dependencies` (already the full transitive closure - see
  * `Repository`'s own `_updateDependencies`) and their results are unioned in - so `--deps
@@ -46,7 +166,7 @@ export declare function filterPackages(packages: Package[], options: PackageFilt
  */
 applySkip?: boolean): Package[];
 /**
- * `--root`/`-r`, with one describe text instead of four near-identical ones.
+ * `--from-root`/`-r`, with one describe text instead of four near-identical ones.
  *
  * **It only means anything where a command scopes by the current directory** - `run`/`build`/`test`,
  * `exec`, `clean`, `changelog` and `diff` narrow to `Repository.currentPackage` when you stand
@@ -54,10 +174,17 @@ applySkip?: boolean): Package[];
  * repository (`version`, `publish`, `list`, `changed`) it would be a flag that does nothing, which
  * is worse than not offering it: a no-op flag reads as a promise.
  *
+ * That same rule is why there is no `--root-only` beside it, however naturally the pair reads: it
+ * would be a no-op on `run`/`build`/`test` (the root is not in `repository.packages` at all and
+ * contributes only `pre`/`post` bookends), identical to this flag on `diff`, already what this flag
+ * does on `config`, and on `clean` actively misleading - the root's own sweep recurses through
+ * `packages/*`, so a `--root-only` there deletes *more* than a package-scoped run, not less
+ * (measured). Where the root genuinely is a candidate, `--scope /` says so - see `ROOT_SELECTOR`.
+ *
  * `verb` is the command's own word for what it does, so the text stays the sentence each command was
  * already saying.
  */
-export declare function applyRootOption<T>(cmd: Argv<T>, verb: string): Argv<T>;
-/** The `--root` flag as the services read it - beside `readPackageFilterOptions`, so a command
+export declare function applyFromRootOption<T>(cmd: Argv<T>, verb: string): Argv<T>;
+/** The `--from-root` flag as the services read it - beside `readPackageFilterOptions`, so a command
  *  reads both the same way. */
-export declare function readRootOption(args: any): boolean | undefined;
+export declare function readFromRootOption(args: any): boolean | undefined;