rman 1.3.0 → 2.0.0-beta.3

package/README.md

@@ -66,7 +66,7 @@ rman version
 # Apply it: bump versions, write CHANGELOG.md, commit, tag
 rman version --changelog
 
-# Publish everything that isn't already on the registry (needs rman-node)
+# Publish everything that isn't already on the registry
 rman publish
 ```
 
@@ -86,21 +86,32 @@ worked examples of every single command, see **[docs/cli-rman.md](https://github
 | [`test`](#rman-test) | Alias for `run test`. |
 | [`exec <command..>`](#rman-exec-command) | Runs an arbitrary shell command in each package. |
 | [`config`](#rman-config) | Prints the effective `.rmanrc` config for the current directory's package. |
-| [`changed`](#rman-changed) | Shows which packages the next `version` run would bump. |
 | [`diff [package]`](#rman-diff-package) | Shows the git diff since a package's (or the repo's) last release tag. |
 | [`changelog`](#rman-changelog) | Generates a changelog per package from unreleased commits. |
 | [`version [bump]`](#rman-version-bump) | Bumps versions of changed packages (and their dependents). |
+| [`publish`](#rman-publish) | Publishes every package whose version isn't on its registry yet. |
 | [`github-release`](#rman-github-release) | Creates the repository's GitHub Release for its release tag. |
 | [`import <path>`](#rman-import-path) | Imports an external git repository as a new package, with history. |
 
-**`publish`, `ci` and `clean` come from [`rman-node`](https://www.npmjs.com/package/rman-node)**,
-not from this package - each is about npm or TypeScript rather than about repositories. Name the
-plugin in `.rmanrc` to get them:
+**`ci` and `clean` come from the `node` built-in**, which ships inside this package - each is about
+npm or TypeScript rather than about repositories, so nothing it contributes exists until a
+repository asks for it:
 
 ```yaml
-plugins: ['rman-node']
+plugins: ['node']   # by name
+platform: node      # the same statement at a repository root, plus which technology its packages are
 ```
 
+Or say nothing: a repository that declares no technology gets the one its own files imply, announced
+on stderr rather than guessed silently. It used to take a second package (`rman-node`) and a
+`.rmanrc` before anything worked at all.
+
+**`publish` is here, but *where* a package ships is a plugin's to say.** A **publish target** is
+one answer to "is this version on the registry, and how do I push it" - rman ships `docker`
+(any language's project can push an image), and the `node` built-in contributes `npm` with the flags
+that only mean something there (`--access`, `--tag`, `--otp`, `--registry`, ...). So
+`rman publish --help` lists what this repository's targets actually understand.
+
 Options shared across several commands:
 
 - **`skip`** (`.rmanrc`, per package): leave this package alone - honoured by every command that
@@ -108,8 +119,10 @@ Options shared across several commands:
 - **Package filtering** (`list`, `run`/`build`/`test`, `exec`, `version`, `changelog`, and a
   plugin's own commands): `--scope <glob>`, `--ignore <glob>`, `--deps`, `--dependents` - see
   [Package filtering](https://github.com/panates/rman/blob/main/docs/rman.md#package-filtering-scopeignoredepsdependents)
-  for the full semantics.
-- **`--root`/`-r`** (every command that narrows to the package you are standing in -
+  for the full semantics. **`--scope /` is the repository's own root package** - the same `/`
+  `.rmanrc`'s `"[/]"` block uses, and not a glob, so `--scope '*'` means the members and a glob
+  never picks up the root by name.
+- **`--from-root`/`-r`** (every command that narrows to the package you are standing in -
   `run`/`build`/`test`, `exec`, `changelog`, `diff`): run against the whole repository instead.
 - **Branch guard** (every command that mutates state or runs scripts - `run`/`build`/`test`,
   `exec`, `version`): `--allow-branch <glob>`, `--ignore-branch <glob>` -
@@ -127,16 +140,17 @@ rman list --json                # full detail as JSON
 rman list --parseable           # location::name::version::PRIVATE::STATUS lines, for scripting
 rman list --toposort            # dependencies before dependents, instead of directory order
 rman list --graph               # dependency graph as a JSON adjacency list
-rman list --changed             # only packages changed since the last publish
+rman list --changed             # only packages you have touched but not pushed
 rman list --changed-since HEAD~5
 rman list --scope '@myorg/*' --ignore '*-internal'
 ```
 
 ### `rman info`
 
-Prints local environment (OS/CPU/memory, Node, git) and repository information. A plugin adds its
-own ecosystem's part - `rman-node` reports whichever package manager `.rmanrc "packageManager"`
-names, plus the installed `rman` packages.
+Prints local environment (OS/CPU/memory, Node, git) and repository information. A platform adds its
+own ecosystem's part - the `node` built-in reports whichever package manager
+`.rmanrc "packageManager"` names, plus the installed `rman` packages, and only in a repository that
+asked for it.
 
 ```bash
 rman info
@@ -150,7 +164,7 @@ Runs an npm script in each package, in dependency order by default.
 ```bash
 rman run build
 rman run lint --topo=false          # independent packages, alphabetical order, no dependency waiting
-rman run test --changed             # only in packages changed since the last publish
+rman run test --changed             # only in packages you have touched but not pushed
 rman run build --changed-since v1.2.0
 rman run build --parallel 4         # at most 4 packages at once
 rman run build --parallel false     # serially, one at a time
@@ -192,24 +206,15 @@ rman exec --topo=false pwd         # every package independently, alphabetical o
 ### `rman config`
 
 Prints the **effective** config for the package of the current directory - after the directory
-cascade, `"[selector]"` blocks, `extends`, `+key` appends and `${{ ... }}` expressions have all been
+cascade, `"[selector]"` blocks, `extends` and `${{ ... }}` expressions have all been
 applied. What rman actually sees there, which no single file shows.
 
 ```bash
 rman config                  # the package you are standing in
-rman config --root           # the repository root's own config instead
+rman config --from-root           # the repository root's own config instead
 rman config --json | jq .run
 ```
 
-### `rman changed`
-
-Shows which packages the next `rman version` run would bump, without changing anything.
-
-```bash
-rman changed
-rman changed --json
-```
-
 ### `rman diff [package]`
 
 Shows the git diff since a package's (or the whole repository's) last release tag.
@@ -266,6 +271,29 @@ Release-As: patch
 See [docs/rman.md#versionservice](https://github.com/panates/rman/blob/main/docs/rman.md#versionservice) for the full grouping/propagation
 algorithm, prerelease semantics, and `"workspace:"` dependency-range handling.
 
+### `rman publish`
+
+Publishes every package whose current version isn't on its registry yet. Shows the plan first, then
+asks for confirmation (unless `--yes` or `--dry-run`), then publishes in topological order,
+dependencies before dependents.
+
+```bash
+rman publish                    # show the plan, then ask for confirmation
+rman publish --yes              # publish immediately, no confirmation
+rman publish --dry-run --json   # "is there anything to release?", for a CI gate
+rman publish --target docker    # only the packages configured for that target
+```
+
+**Where a package ships is a publish target, and a target is a contribution.** rman ships `docker`;
+the `node` built-in contributes `npm`. A package says where it goes with `.rmanrc "publish.target"`, or says
+nothing and goes wherever the installed targets claim it - so a Cargo package is never assumed to be
+an npm one. Each target adds its own flags, so `rman publish --help` is worth reading in your own
+repository. See
+[docs/cli/publish.md](https://github.com/panates/rman/blob/main/docs/cli/publish.md).
+
+It never looks at whether `version` ran: it inspects what is on disk and on each registry, so it
+behaves the same right after a bump or days later, and re-running is safe.
+
 ### `rman github-release`
 
 Creates the repository's GitHub Release for the version that just shipped - one per run, named after
@@ -294,7 +322,7 @@ rman import ../my-old-standalone-repo --dest libs   # under libs/ instead of pac
 already. After importing, add the new directory to your `workspaces` glob if it isn't already
 covered, then run `rman ci` to install it.
 
-## Shared config (`extends`) and appending (`+key`)
+## Shared config (`extends`) and adding to it (`value`)
 
 House rules live in one package, and a repository names it:
 
@@ -305,13 +333,18 @@ extends: '@panates/rman-monorepo'
 '[*]':
   run:
     build:
-      +before: 'rm -rf ./cache' # adds to the base's step, rather than replacing it
+      # adds to the base's step, rather than replacing it
+      before: "${{ [...value, 'rm -rf ./cache'] }}"
 ```
 
 `extends` merges underneath the file naming it (a package, a path, or a list), and may itself be
-chained. `+key` appends to whatever the key already resolved to - from the base, a parent directory,
-or a selector - which is what lets a repository add one step without restating a list it doesn't
-own. See [docs/rman.md](https://github.com/panates/rman/blob/main/docs/rman.md#inheriting-a-shared-config-extends).
+chained. `value` is what the key already resolved to - from the base, a parent directory, or a
+selector - which is what lets a repository add one step without restating a list it doesn't own. It
+is the list form of whatever is underneath, so the spread needs no guard even when nothing is.
+See [docs/rman.md](https://github.com/panates/rman/blob/main/docs/rman.md#inheriting-a-shared-config-extends).
+
+There was a `+key` prefix for this and it is gone; one still in a config is refused, naming what to
+write instead.
 
 ## Your own commands
 
@@ -408,8 +441,9 @@ import { defineConfig } from 'rman';
 export default defineConfig({ allowBranch: ['main'] });
 ```
 
-With a plugin, import `defineConfig` from the plugin instead (`rman-node`'s carries its own keys
-into the type). The `.rmanrc`/`.rmanrc.yml` forms get no checking - see
+A plugin's keys arrive by declaration merging, so annotating with `RmanConfig` types them too;
+`RmanNodeConfig` is the alias that says out loud which set a config is using. The
+`.rmanrc`/`.rmanrc.yml` forms get no checking - see
 [docs/rman.md#editor-support-types](https://github.com/panates/rman/blob/main/docs/rman.md#editor-support-types) for why the JSON Schema that
 used to cover them was removed.
 

package/builtins/platforms/node/augmentation/rmanrc.augmentation.d.ts

@@ -0,0 +1,83 @@
+import type { cleanCommand, CleanExtraKeys } from '../commands/clean.command.js';
+import type { NodeConfigKeys, RmanNodeConfig } from '../node-config.interface.js';
+import type { CiService } from '../services/ci.service.js';
+/**
+ * **Every type this plugin adds to rman, in one `declare module` block.**
+ *
+ * **One block was once forced and is now only convenient.** While this shipped as its own package
+ * it augmented the *package name* `'rman'`, and a second such block anywhere silently disabled the
+ * first - measured, `SystemInfo.PackageManager` went unresolved at four call sites with nothing
+ * pointing at the cause. Bundled into rman, these augment a **module path** like every built-in
+ * command's own contribution does, and that limit is gone; they stay together because the plugin's
+ * types read better in one place, not because they have to.
+ *
+ * Type-only. The runtime half of each augmentation lives with its own subject
+ * (`augmentSystemInfo()`, `augmentManifest()`, ...); this file is imported by the plugin's entry
+ * point purely so a consumer's compiler loads it.
+ */
+declare module '../../../../interfaces/rman-config.interface.js' {
+    /**
+     * The `.rmanrc` keys that only mean something in a Node repository - merged into the core's own
+     * key list, so `pkg.config.clean` is typed wherever it is read (`CleanService` included) without
+     * a cast, and without the core declaring a key it knows nothing about.
+     *
+     * The augmentation is evaluated where it is used, so `clean` is typed at the place it is read.
+     */
+    interface RmanConfigKeys extends NodeConfigKeys {
+    }
+    /**
+     * **`clean.*`, contributed by the command that reads it**, the way every built-in contributes its
+     * own key - `skip` derived from the command's `config` block, `include`/`exclude` hand-written in
+     * `CleanExtraKeys` because a `CommandOption` cannot say "a glob *or* a list of them".
+     *
+     * It is declared here rather than beside the command only because of the one-block rule above.
+     * rman's own commands put theirs next to themselves, augmenting a module path instead of a
+     * package name, which has no such limit.
+     */
+    namespace RmanConfig {
+        interface CommandConfigs extends RmanConfig.CommandContribution<ReturnType<typeof cleanCommand>, CleanExtraKeys> {
+        }
+    }
+}
+/**
+ * **The `npm` target's own `publish.*` block** - declared into the slot `publish` exports, exactly
+ * where the core's own `docker` target declares `publish.docker`.
+ *
+ * A *different* module from the block above, and that is the shape the fold made possible: while
+ * this shipped as `rman-node` everything had to augment the one package name `'rman'`, so a slot
+ * declared in `publish.command.ts` was reachable only by re-declaring it - which now reads as two
+ * interfaces of one name and is refused. Each interface is augmented where it lives.
+ */
+declare module '../../../../commands/publish.command.js' {
+    /**
+     * The `npm` publish target's own `publish.*` block, declared the way the core's `docker` target
+     * declares `publish.docker` - through the slot `publish` contributes, rather than into a central
+     * `PublishOptionsKeys` that the core owned.
+     *
+     * That is the config half of a target being a contribution: this package brings the flags, the
+     * registry check, *and* the keys, and none of it is written down in rman.
+     */
+    interface PublishTargetConfigs {
+        /** The `npm` target's block, named after the target exactly as the core's `docker` one is. */
+        npm?: RmanNodeConfig.NpmPublishOptions;
+    }
+}
+/**
+ * **The npm half of `SystemInfo`** - what `rman info` reports once a repository is a Node one. The
+ * runtime half is `augmentSystemInfo()` in the file beside this one, called when the built-in is
+ * registered rather than at import, so a repository that never named it reports no npm.
+ */
+declare module '../../../../services/system-info.js' {
+    namespace SystemInfo {
+        type PackageManager = CiService.PackageManager;
+        interface Options {
+            /**
+             * Report this package manager's version under `Binaries`, plus the `npmPackages` sections.
+             *
+             * Defaults to `.rmanrc "packageManager"` (read off `Options.repository`), then to `npm` -
+             * this package being installed is itself the statement that the repository is a Node one.
+             */
+            packageManager?: PackageManager;
+        }
+    }
+}

package/builtins/platforms/node/augmentation/system-info.augmentation.d.ts

@@ -0,0 +1,26 @@
+/**
+ * Adds the npm half of `SystemInfo` to rman's own types.
+ *
+ * The core's `Options` carries nothing language-specific on purpose, so `packageManager` is not a
+ * setting it hid behind a flag - it is a setting it does not have. Declaration merging is what lets
+ * this package add it as if it had always been there, `SystemInfo.PackageManager` included, without
+ * the core naming npm anywhere.
+ *
+ * The union itself is `CiService.PackageManager`, not a second copy: `ci` and `publish` already
+ * shell out to one of these, and two lists of the same four names drift the moment a fifth appears.
+ */
+/** The import above is aliased precisely so this block can use the real name: declaration merging
+ *  keys off the module specifier, not off any local binding, so `namespace SystemInfo` here *is*
+ *  rman's - and nothing shadows anything. */
+/** The `SystemInfo` types this file's wrapper relies on are declared in
+ *  [`rman.augmentation.ts`](rman.augmentation.ts), with the rest of this plugin's - one
+ *  `declare module` block per package, or the others stop applying. */
+/**
+ * Turns the npm half on at runtime.
+ *
+ * Applied by wrapping rather than by a flag on the core service: "is this a Node repository" is not
+ * a question rman's core should be able to ask, and a `nodejs: true` option there would be exactly
+ * that question wearing a different hat. The wrapper translates `packageManager` into the `envinfo`
+ * categories the core knows nothing about.
+ */
+export declare function augmentSystemInfo(): void;

package/builtins/platforms/node/augmentation/system-info.augmentation.js

@@ -0,0 +1,79 @@
+import { SystemInfo as OrgSystemInfo } from '../../../../services/system-info.js';
+/**
+ * Adds the npm half of `SystemInfo` to rman's own types.
+ *
+ * The core's `Options` carries nothing language-specific on purpose, so `packageManager` is not a
+ * setting it hid behind a flag - it is a setting it does not have. Declaration merging is what lets
+ * this package add it as if it had always been there, `SystemInfo.PackageManager` included, without
+ * the core naming npm anywhere.
+ *
+ * The union itself is `CiService.PackageManager`, not a second copy: `ci` and `publish` already
+ * shell out to one of these, and two lists of the same four names drift the moment a fifth appears.
+ */
+/** The import above is aliased precisely so this block can use the real name: declaration merging
+ *  keys off the module specifier, not off any local binding, so `namespace SystemInfo` here *is*
+ *  rman's - and nothing shadows anything. */
+/** The `SystemInfo` types this file's wrapper relies on are declared in
+ *  [`rman.augmentation.ts`](rman.augmentation.ts), with the rest of this plugin's - one
+ *  `declare module` block per package, or the others stop applying. */
+/**
+ * Turns the npm half on at runtime.
+ *
+ * Applied by wrapping rather than by a flag on the core service: "is this a Node repository" is not
+ * a question rman's core should be able to ask, and a `nodejs: true` option there would be exactly
+ * that question wearing a different hat. The wrapper translates `packageManager` into the `envinfo`
+ * categories the core knows nothing about.
+ */
+export function augmentSystemInfo() {
+    const base = OrgSystemInfo.getSystemInfo;
+    /**
+     * Idempotent, and marked on **the function** rather than in a module-level flag: the flag made
+     * re-application impossible once anything had replaced `getSystemInfo` - a test substituting a
+     * stub, or a second augmentation layering on - so whether the wrapper was actually installed came
+     * down to import order. Asking the current implementation whether it is already wrapped cannot go
+     * stale that way.
+     */
+    if (base[AUGMENTED])
+        return;
+    /** A namespace's exported function is a property of a plain object at runtime, so this is an
+     *  ordinary assignment - the ESM *binding* is immutable, the object it points at is not. */
+    const wrapped = options => {
+        /** An explicit argument first, then the repository's own config, then npm. The config step is
+         *  why the core declares `Options.repository`: `rman info` passes only that, so without it a
+         *  pnpm repository would silently be reported as an npm one. */
+        const packageManager = options?.packageManager ?? asPackageManager(options?.repository?.config?.packageManager) ?? 'npm';
+        return base({
+            ...options,
+            envinfo: {
+                /** Replaces the core's `Binaries: ['Node']` - `envinfo` categories merge by key, not by
+                 *  concatenation, so the whole list has to be restated. */
+                Binaries: ['Node', PACKAGE_MANAGER_BINARY[packageManager]],
+                /** This package's own version alongside rman's - when `info` is being read to work out why
+                 *  a command behaved oddly, which plugin version is installed is half the answer. */
+                npmPackages: ['rman', 'typescript'],
+                npmGlobalPackages: ['typescript'],
+                ...options?.envinfo,
+            },
+        });
+    };
+    wrapped[AUGMENTED] = true;
+    OrgSystemInfo.getSystemInfo = wrapped;
+}
+/** `.rmanrc "packageManager"` value -> the `Binaries` key `envinfo` recognizes for it (`npm`/
+ *  `pnpm`/`bun` are lowercase, `Yarn` isn't - envinfo's own naming, not ours). */
+const PACKAGE_MANAGER_BINARY = {
+    npm: 'npm',
+    yarn: 'Yarn',
+    pnpm: 'pnpm',
+    bun: 'bun',
+};
+/** A config value is whatever the file said, so an unrecognized one is ignored rather than used to
+ *  index `PACKAGE_MANAGER_BINARY` and produce `Binaries: ['Node', undefined]`. */
+function asPackageManager(value) {
+    return typeof value === 'string' && value in PACKAGE_MANAGER_BINARY
+        ? value
+        : undefined;
+}
+/** Marks an implementation as already wrapped. A symbol rather than a property name so it cannot
+ *  collide with anything `envinfo` or a future core option carries. */
+const AUGMENTED = Symbol.for('rman.node.systemInfo.augmented');

package/builtins/platforms/node/commands/ci.command.d.ts

@@ -0,0 +1,133 @@
+import type { ArgsOf } from '../../../../index.js';
+/** Hoisted out of the metadata literal so the handler can be annotated against them - see
+ *  `RmanConfig.ArgsOf` for why an inferred `argv` and the metadata's own typo checking cannot both
+ *  work in one signature. */
+declare const COMMAND: "ci";
+declare const config: {
+    packageManager: {
+        target: "cli";
+        cliName: string;
+        describe: string;
+        choices: readonly ["npm", "yarn", "pnpm", "bun"];
+    };
+    progress: {
+        target: "cli";
+        describe: string;
+        type: "boolean";
+    };
+    allowBranch: {
+        target: "cli";
+        cliName: string;
+        describe: string;
+        type: "string";
+    };
+    ignoreBranch: {
+        target: "cli";
+        cliName: string;
+        describe: string;
+        type: "string";
+    };
+    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";
+    };
+};
+type Args = ArgsOf<typeof config, typeof COMMAND>;
+/**
+ * `rman ci` - contributed by the `node` built-in rather than always present.
+ *
+ * **Declared, not built.** This was a `CustomCommand` with a hand-written `builder` chaining
+ * `applyBranchGuardOptions(applyPackageFilterOptions(cmd))`, which is the shape every built-in had
+ * before the options became data. A plugin's command uses the identical declaration now -
+ * `declareCommand` rather than `registerCommand`, which is the one difference and the reason for
+ * it: `registerCommand` pushes onto a module-level registry that `runCli` always walks, so a plugin
+ * using it would hand `ci` to repositories that are not Node ones.
+ *
+ * The repository arrives through `app` when the factory runs (in `cli.ts`, after `Repository.create`
+ * has attached one), rather than through a `CommandContext` per invocation.
+ */
+export declare const ciCommand: (app: import("../../../../index.js").RmanApplication) => {
+    command: "ci";
+    /** npm's alone: it installs through a Node package manager, from a Node lockfile. */
+    platforms: string[];
+    describe: string;
+    /** Read, not owned: `packageManager` is a root-level key this package declares in
+     *  `NodeConfigKeys`, and the `npm` publish target reads it too. */
+    configKeys: string[];
+    config: {
+        packageManager: {
+            target: "cli";
+            cliName: string;
+            describe: string;
+            choices: readonly ["npm", "yarn", "pnpm", "bun"];
+        };
+        progress: {
+            target: "cli";
+            describe: string;
+            type: "boolean";
+        };
+        allowBranch: {
+            target: "cli";
+            cliName: string;
+            describe: string;
+            type: "string";
+        };
+        ignoreBranch: {
+            target: "cli";
+            cliName: string;
+            describe: string;
+            type: "string";
+        };
+        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";
+        };
+    };
+    examples: {
+        command: string;
+    }[];
+    handler: (args: Args) => Promise<void>;
+};
+export {};

package/builtins/platforms/node/commands/ci.command.js

@@ -0,0 +1,60 @@
+import { declareCommand } from '../../../../interfaces/rman-config.interface.js';
+import { assertAllowedBranch, branchGuardOptions, readBranchGuardOptions } from '../../../../utils/branch-guard.js';
+import { packageFilterOptions, readPackageFilterOptions } from '../../../../utils/package-filter.js';
+import { CiService } from '../services/ci.service.js';
+/** Hoisted out of the metadata literal so the handler can be annotated against them - see
+ *  `RmanConfig.ArgsOf` for why an inferred `argv` and the metadata's own typo checking cannot both
+ *  work in one signature. */
+const COMMAND = 'ci';
+const config = {
+    ...packageFilterOptions,
+    ...branchGuardOptions,
+    packageManager: {
+        target: 'cli',
+        cliName: 'package-manager',
+        describe: 'Package manager to install with (default: npm, or .rmanrc "packageManager")',
+        choices: CiService.PACKAGE_MANAGERS,
+    },
+    progress: {
+        target: 'cli',
+        describe: 'Show a live progress panel while running (default: true; auto-disabled when not a TTY). ' +
+            'Unlike run/build, completion is not reported as a per-package tally - only failures are called out.',
+        type: 'boolean',
+    },
+};
+/**
+ * `rman ci` - contributed by the `node` built-in rather than always present.
+ *
+ * **Declared, not built.** This was a `CustomCommand` with a hand-written `builder` chaining
+ * `applyBranchGuardOptions(applyPackageFilterOptions(cmd))`, which is the shape every built-in had
+ * before the options became data. A plugin's command uses the identical declaration now -
+ * `declareCommand` rather than `registerCommand`, which is the one difference and the reason for
+ * it: `registerCommand` pushes onto a module-level registry that `runCli` always walks, so a plugin
+ * using it would hand `ci` to repositories that are not Node ones.
+ *
+ * The repository arrives through `app` when the factory runs (in `cli.ts`, after `Repository.create`
+ * has attached one), rather than through a `CommandContext` per invocation.
+ */
+export const ciCommand = declareCommand(app => {
+    const repository = app.repository;
+    return {
+        command: COMMAND,
+        /** npm's alone: it installs through a Node package manager, from a Node lockfile. */
+        platforms: ['node'],
+        describe: 'Deletes node_modules and lockfiles in every package, then reinstalls from scratch',
+        /** Read, not owned: `packageManager` is a root-level key this package declares in
+         *  `NodeConfigKeys`, and the `npm` publish target reads it too. */
+        configKeys: ['packageManager'],
+        config,
+        examples: [{ command: '$0 ci' }],
+        handler: async (args) => {
+            await assertAllowedBranch(repository, readBranchGuardOptions(args));
+            await CiService.reinstall(repository, {
+                ...readPackageFilterOptions(args),
+                packageManager: args.packageManager,
+                progress: args.progress,
+                logLevel: args.logLevel,
+            });
+        },
+    };
+});