rman 1.2.5 → 2.0.0-beta.2

package/core/plugin-loader.js

@@ -0,0 +1,234 @@
+import path from 'node:path';
+import { pathToFileURL } from 'node:url';
+import fastGlob from 'fast-glob';
+import { COMMANDS_KEY } from './merge-config.js';
+import { isDeclared, isPlatform } from './plugin.js';
+/** The `.rmanrc` key naming plugin packages to load. */
+export const PLUGINS_KEY = 'plugins';
+/**
+ * The repository's plugins and publish targets, registered onto `app`.
+ *
+ * **Three keys share one shape** - `plugins`, `publishTargets` and `commands` each take an
+ * instance or a **glob** naming `.js` modules that `export default` one, and each appends rather
+ * than replaces. Two of them are read here; `commands` is read by `cli.ts`, and the split is not
+ * arbitrary:
+ *
+ * - **`plugins` and `publishTargets` are root-level, because they have to be.** This runs inside
+ *   `Repository.create` *before* the packages are known, since a plugin's `getWorkspace` is what
+ *   finds them - so there are no package configs to read yet. A `plugins` entry in a package's own
+ *   `.rmanrc` is never seen, which has always been true and is now true for the same reason.
+ * - **`commands` is read at any level**, after the packages exist, which is why `cli.ts` owns it:
+ *   it already holds the whole command pipeline - the `.rman/` default, de-duplication by name,
+ *   and the built-in shadow check. Reading it here as well would register every config-declared
+ *   command twice, and yargs does not survive that.
+ *
+ * **Order within this function is load-bearing**: plugins first, then targets. rman's own
+ * `publish` builds its `--target` choices from `app.publishTargets` when its factory runs, and a
+ * target contributed by a plugin's `init` has to be there before the list is read.
+ *
+ * **A contribution that cannot be loaded throws**, unlike a broken `.rman/*.mjs`, which is warned
+ * about and skipped. The consequence differs: a skipped local command affects only itself, while a
+ * missing plugin silently removes commands the repository is built around - `rman publish` would
+ * simply not exist, and "not a known command" sends the reader looking in the wrong place.
+ */
+export async function loadPlugins(app, rootConfig) {
+    const seen = new Set();
+    for (const { value, from } of await resolveEntries(rootConfig.plugins, PLUGINS_KEY)) {
+        const plugin = value;
+        if (!isPlainObject(plugin) || typeof plugin.name !== 'string' || !plugin.name) {
+            throw new Error(`"${PLUGINS_KEY}" takes a plugin or a glob naming modules that export one - ${from} gave ` +
+                `${describeExport(plugin)}. Every message about a plugin is keyed by its \`name\`.`);
+        }
+        /**
+         * **Declared through `definePlatform`/`definePlugin`, and checked for it.**
+         *
+         * The guard used to be `manifestProvider` being required, which worked only while one type was
+         * both halves. A 2.x plugin that contributes nothing but an `init` is `{ name, init }` - and so
+         * was an rman **1.x plugin**, exactly. They are indistinguishable by shape, so a shape test
+         * cannot tell them apart and the declaration has to be explicit.
+         *
+         * Measured on the real case before there was any guard: `@panates/rman-node`'s 1.x plugin
+         * loaded, registered, and died inside its own `init` with
+         * `TypeError: ctx.addCommand is not a function`, fifteen times over, naming neither the plugin
+         * nor the version it was written against.
+         */
+        if (!isDeclared(plugin)) {
+            throw new Error(`Plugin "${plugin.name}" (${from}) was not declared with definePlatform() or ` +
+                `definePlugin(). A plain object is how an rman 1.x plugin looks, and a 1.x plugin has ` +
+                `nothing left to do: commands, publish targets and other plugins are "${COMMANDS_KEY}", ` +
+                `"publishTargets" and "${PLUGINS_KEY}" keys of a config now. Wrap a technology in ` +
+                `definePlatform({ name, manifestProvider, ... }), anything else in definePlugin({ ... }).`);
+        }
+        /** One registration per name. Twice would define the same commands twice, which yargs does not
+         *  survive - and two layers naming one plugin is ordinary rather than a mistake. */
+        if (seen.has(plugin.name))
+            continue;
+        seen.add(plugin.name);
+        await registerPlugin(app, plugin).init?.({ app });
+    }
+    for (const { value, from } of await resolveEntries(rootConfig.publishTargets, 'publishTargets')) {
+        const target = value;
+        if (!isPlainObject(value) || typeof target.name !== 'string' || !target.name) {
+            throw new Error(`"publishTargets" takes a target or a glob naming modules that export one - ${from} gave ` +
+                `${describeExport(target)}.`);
+        }
+        app.publishTargets.add(target);
+    }
+}
+/**
+ * **Puts one plugin onto an application** - what `plugins` does with an entry once it has been
+ * found and vetted, and the only place that knows how.
+ *
+ * **A bare `Platform` is sugar**, which is what almost every entry is - a plugin that provides one
+ * technology and nothing else. Normalized here, so nothing downstream deals in two shapes.
+ *
+ * **Exported because a spec must not reimplement it.** The registration is two registries plus a
+ * planner assignment, and a fixture writing that out by hand is a second implementation that
+ * drifts - which is exactly how a fixture ends up proving the core works when it does not. A spec
+ * brings its own technology through this, the same door a config's does.
+ *
+ * **`init` is not called here, and that is why this returns the normalized plugin.** An `init` runs
+ * once, when a *config* brought the plugin in, and it may be asynchronous - so it belongs to the
+ * loader above rather than to a function a fixture calls synchronously while building an
+ * application.
+ */
+export function registerPlugin(app, entry) {
+    const declared = isPlatform(entry) ? { name: entry.name, platforms: [entry] } : entry;
+    app.plugins.add(declared);
+    for (const platform of declared.platforms ?? []) {
+        app.platforms.add(platform);
+        /**
+         * **The orchestrator, and only that.** A plan is computed for the whole repository at once -
+         * groups span packages, the ripple crosses them - so one planner drives the traversal and the
+         * last registration wins it.
+         *
+         * The two decisions that belong to a *technology* are not taken from here: `detectBoundary`
+         * and `cascade` are asked of `pkg.platform.versionPlanner` per package, which is why a platform
+         * still declares one even when it is not the last to register.
+         */
+        if (platform.versionPlanner)
+            app.versionPlanner = platform.versionPlanner;
+    }
+    return declared;
+}
+/**
+ * The shared half of the three keys: an instance is itself, a string is a glob whose matches are
+ * imported and unwrapped.
+ *
+ * **A glob is already absolute** by the time it gets here - `mergeConfig` anchors it to the file
+ * that declared it as the config is read, which is the last moment that is knowable (see
+ * `anchorContributions`). Nothing here resolves a path.
+ *
+ * **`.js` only.** rman imports these in its own process with no loader registered, so a `.ts`
+ * module cannot be one; a TypeScript repository compiles first or writes `.mjs`. Stated rather
+ * than attempted, because a `.ts` that happens to load under a test runner's loader and not under
+ * the CLI is the worst of both.
+ */
+async function resolveEntries(declared, key) {
+    if (declared === undefined)
+        return [];
+    const out = [];
+    for (const entry of (Array.isArray(declared) ? declared : [declared])) {
+        if (typeof entry !== 'string') {
+            out.push({ value: entry, from: `"${key}"` });
+            continue;
+        }
+        if (!entry.trim())
+            throw new Error(`"${key}" has an empty glob.`);
+        const files = await fastGlob(entry.split(path.sep).join('/'), { absolute: true, onlyFiles: true });
+        /**
+         * **A glob matching nothing is an error here**, unlike in `commands`, and the asymmetry is the
+         * point. Losing a plugin silently removes commands and seams the repository is built around -
+         * `rman publish` would simply not exist, and "not a known command" sends the reader looking in
+         * the wrong place. `commands` can match nothing legitimately: `.rman/*.js` is its default, and
+         * most repositories have no such directory.
+         */
+        if (!files.length) {
+            /**
+             * **A package name gets the answer it is actually asking for.** A bare `rman-node` here is a
+             * glob that matches nothing, and "matched no file" sends the reader to check their paths -
+             * when what they wrote is a *package*, whose config reaches a repository through `extends`.
+             * Two documents promised this message named the fix (`docs/rman.md`, `docs/cli-rman.md`) and
+             * it did not; measured, `plugins: ['rman-node']` exited 1 saying only that a glob matched
+             * nothing.
+             *
+             * Reaching this intact takes `mergeConfig`'s help: it anchors a contribution glob to the file
+             * that declared it, which used to turn `rman-node` into `<dir>/rman-node` and erase the
+             * evidence. `looksLikePackageName` there leaves this shape alone; the same predicate is
+             * spelled again here rather than shared, because the two modules answer different questions
+             * with it and a merge concern importing a loader concern (or the reverse) is the coupling
+             * neither wants.
+             */
+            const isPackageName = /^(?:@[a-z0-9-~][\w.-]*\/)?[a-z0-9-~][\w.-]*$/i.test(entry) && !/\.[cm]?js$/i.test(entry);
+            if (isPackageName) {
+                throw new Error(`"${key}" entry "${entry}" looks like a package name, and this key does not take one - ` +
+                    `it takes a plugin, or a glob naming modules that export one. A plugin package exports ` +
+                    `an rman config, so write \`extends: "${entry}"\` instead, which merges everything that ` +
+                    `package declares underneath your own config.`);
+            }
+            throw new Error(`"${key}" glob "${entry}" matched no file. A plugin that does not load is not a plugin.`);
+        }
+        for (const file of [...new Set(files.map(f => path.resolve(f)))].sort()) {
+            const mod = await import(pathToFileURL(file).href);
+            const exported = mod?.default;
+            if (exported === undefined) {
+                throw new Error(`"${key}" matched "${file}", which has no default export. ${describeExport(mod)}`);
+            }
+            out.push({ value: exported, from: file });
+        }
+    }
+    return out;
+}
+/**
+ * The second half of the error above - what the module *did* export, so the author can see how far
+ * off it was.
+ *
+ * It recognizes a plugin object only to **say so in a message**. That is the one safe use for this
+ * shape test: it decides nothing, so a wrong guess costs a slightly less helpful sentence rather
+ * than a plugin that silently does not load.
+ */
+function describeExport(exported) {
+    if (exported === undefined)
+        return 'It has no default export.';
+    if (!isPlainObject(exported))
+        return `Its default export is a ${typeof exported}.`;
+    const looksLikePlugin = PLUGIN_SEAMS.some(seam => exported[seam] !== undefined);
+    return looksLikePlugin
+        ? `Its default export looks like the plugin itself - put it in a config's "${PLUGINS_KEY}".`
+        : `Its default export has no "${PLUGINS_KEY}".`;
+}
+/**
+ * The members only a plugin has, for that sentence alone.
+ *
+ * **`name` is deliberately not one of them**, and it used to be: a config may carry a `name` too,
+ * so anything with one "looked like a plugin" - which sent the author of a perfectly ordinary
+ * config to go and wrap it in `plugins`. Each of these belongs to a technology and to nothing
+ * else, `manifestProvider` first because it is the one a plugin cannot be without.
+ */
+const PLUGIN_SEAMS = ['manifestProvider', 'getWorkspace', 'getBinPaths', 'getRunSteps', 'versionPlanner'];
+/** A config object, as opposed to an array or anything with its own prototype. */
+function isPlainObject(value) {
+    return !!value && typeof value === 'object' && !Array.isArray(value);
+}
+/**
+ * A plugin's `CustomCommand`, checked the same way a `.rman/*.mjs` one is - the name it answers to
+ * comes from its own `command` string, since a plugin has no file name to fall back on.
+ *
+ * Exported because `cli.ts` runs the identical checks on what a *declarative* command's factory
+ * returns, and they must not drift: a plugin written in JavaScript reaches both forms with no type
+ * checker in the way.
+ */
+export function checkCustomCommand(command, pluginName) {
+    const declared = command?.command?.trim();
+    if (!declared) {
+        throw new Error(`Plugin "${pluginName}" has a command with no "command" name - it cannot be registered.`);
+    }
+    if (typeof command.handler !== 'function') {
+        throw new Error(`Plugin "${pluginName}" command "${declared}" has no "handler" function.`);
+    }
+    if (typeof command.describe !== 'string' || !command.describe) {
+        throw new Error(`Plugin "${pluginName}" command "${declared}" has no "describe" - \`rman --help\` would have ` +
+            `nothing to list it by.`);
+    }
+    return { ...command, command: declared };
+}

package/core/plugin.d.ts

@@ -1,112 +1,157 @@
-import type { RmanConfig } from '../interfaces/rman-config.interface.js';
-import { RunService } from '../services/run.service.js';
-import { VersionPlanService } from '../services/version-plan.service.js';
-import { BinPath } from '../utils/bin-path.js';
-import type { CustomCommand, LoadedCommand } from './custom-command.js';
-import { type ManifestProvider } from './manifest.js';
-import { Workspace } from './workspace.js';
-/** The `.rmanrc` key naming plugin packages to load. */
-export declare const PLUGINS_KEY = "plugins";
+import type { RunService } from '../services/run.service.js';
+import type { VersionPlanService } from '../services/version-plan.service.js';
+import type { BinPath } from '../utils/bin-path.js';
+import type { RmanApplication } from './application.js';
+import type { ManifestProvider } from './manifest.js';
+import type { Workspace } from './workspace.js';
 /**
- * What a plugin package hands rman.
+ * **One technology, as a whole** - Node, Cargo, Maven. Everything rman needs in order to treat a
+ * directory as a package of that technology.
  *
- * An object rather than a bare array of commands, for the reason `CommandContext` is one: a plugin
- * will eventually contribute more than commands (config defaults, publish targets, a package
- * provider for a non-Node repository), and nothing written against this should have to change when
- * it does.
+ * **This was called `Plugin`, and the name was a lie.** `manifestProvider` is required, which makes
+ * the type a *platform* by definition: a package that only ships commands never touches it, because
+ * commands are a config key. So the narrow thing took the narrow name, and `Plugin` became the
+ * broad one that may carry platforms - a plugin *provides* platforms, and may provide more than
+ * one (a package shipping both `maven` and `gradle` is one plugin, two platforms).
+ *
+ * These were six independent fields on a plugin, each with its own registry, and declaring one
+ * without the others type-checked. It is not a shape that admits sense: `getRunSteps` reads
+ * `pkg.manifest.raw?.scripts`, so contributing npm's step source without npm's manifest reader
+ * leaves it parsing whatever another technology produced. The coupling was already real; only the
+ * type failed to say so.
+ *
+ * **`RmanPlugin` and `TechStack` used to be two types and are now one.** The plugin existed solely to
+ * *register* the stack - its whole `init` was `ctx.addTechStack(...)` plus a command or two - and
+ * once a config carries commands and publish targets itself, that registration step has nothing
+ * left to do. What remains of a plugin is the technology, so that is what the type is.
+ *
+ * **`manifestProvider` stays grouped rather than flattened in here**, and it was tried the other
+ * way first: nine members about one file - reading it, writing it, what it declares, how its
+ * versions are numbered, stamped and looked up on a registry - are more legible as a named group
+ * than as nine siblings of `getBinPaths`. The name also keeps its distance from `Package.manifest`,
+ * which is the *data* this produces rather than the reader.
+ *
+ * **Everything optional is answered by its absence**, never by a default rman invented - see
+ * `basePlatform`.
  */
-export interface RmanPlugin {
-    /** For error messages and `--help` grouping. Conventionally the package's own name. */
-    name: string;
-    commands?: CustomCommand[];
+export interface Platform {
     /**
-     * Where `run` can find a package's steps besides its `.rmanrc` - `rman-node` contributes
-     * `package.json#scripts` here, with npm's `pre`/`post` lifecycle.
+     * **The ecosystem this speaks for**, surfaced on every package it reads as `Package.platform` -
+     * `'node'` for the built-in of that name. Short and about the technology, not about the file:
+     * `manifestProvider.fileName` already says `package.json`, and a name repeating it would tell a
+     * caller nothing it did not have.
      *
-     * Registered in `plugins` declaration order, and only for plugins the repository actually named:
-     * what a script resolves to is then a function of the config rather than of what happened to be
-     * imported.
+     * This is what lets code that *does* know one ecosystem check before acting on a package -
+     * `if (pkg.platform === 'node')` - which matters most in a repository holding more than one,
+     * since a manifest is read per directory and two packages can legitimately answer to different
+     * technologies. It is also the de-duplication key: registering twice under one name is refused,
+     * because it would define the same commands twice and yargs does not survive that.
      */
-    runSteps?: RunService.StepSource;
-    /**
-     * How this ecosystem's repositories are laid out - `rman-node` reads `workspaces` from the root
-     * `package.json` here.
-     *
-     * Loaded **before any package is known**, since this is what finds them: `Repository.create`
-     * reads the root config, loads the plugins it names, and only then asks. A repository naming no
-     * plugin therefore has no packages beyond itself.
-     */
-    workspace?: Workspace.Provider;
-    /**
-     * Where a package's name and version are written, and how it is numbered - `rman-node`
-     * contributes `package.json` here.
-     *
-     * Registered before any package is constructed, since `Package` reads through it. A repository
-     * naming no plugin therefore gets packages named after their own directories at version
-     * `0.0.0` - see `readManifest`.
-     */
-    manifest?: ManifestProvider;
+    name: string;
+    /** Where this technology's packages keep their identity, and how to change it - reading and
+     *  writing the manifest, what it declares as dependencies, how its versions are numbered,
+     *  stamped, and looked up on a registry. */
+    manifestProvider: ManifestProvider;
+    /** Where this technology's packages are, given the repository root - npm reads `workspaces`,
+     *  Cargo a `[workspace] members`. `undefined` when it does not recognize the root. */
+    getWorkspace?: Workspace.Provider;
+    /** Directories to put in front of a child process's PATH, so a command an author wrote
+     *  (`eslint .`) runs the repository's pinned copy - `node_modules/.bin` walked up the tree, for
+     *  npm. Every plugin contributes, unlike the seams above where the first answer wins: a PATH is
+     *  a list, and a polyglot repository wants both ecosystems' binaries reachable. */
+    getBinPaths?: BinPath.Provider;
     /**
-     * How a release is planned - which packages have changed since their last release and what
-     * version each gets. `rman-node` contributes `NodeVersionPlanService` here.
-     *
-     * **`VersionPlanService` is abstract, so `version`/`changed` do not work without one** (they fail
-     * naming this key). Unlike `manifest` and `workspace`, which degrade to honest defaults, a plan is
-     * either right or it quietly releases the wrong set of packages - see `VersionPlanService`.
+     * What the *package itself* declares for a lifecycle script, from this technology's own files -
+     * npm's `package.json` `scripts`, with `pre<script>`/`<script>`/`post<script>`.
      *
-     * Consulted when a command asks, not at load time, so this is declared and nothing else has to
-     * happen as the plugin's module is imported.
+     * **A query, not a hook, and not build-specific** - which is why it is `getRunSteps` rather than
+     * anything beginning `on`. It returns what the package declares and rman decides what to do with
+     * it; `run`/`build`/`test` ask, and so does `version`, whose `preversion`/`version`/`postversion`
+     * are the same shape (`runLifecycleSlot` -> `contributedSlots`). A name mentioning `build` would
+     * have been wrong about half its callers.
      */
+    getRunSteps?: RunService.StepSource;
+    /** How this technology's releases are planned - where a package's change boundary comes from
+     *  when it has no release tag, and how far into its group a bump reaches. */
     versionPlanner?: VersionPlanService;
-    /**
-     * Where this ecosystem keeps a repository's locally installed executables - `rman-node`
-     * contributes npm's `node_modules/.bin`, walked up the directory chain.
-     *
-     * Prepended to PATH for every `exec`/`runBin` child process, so a command an author wrote runs
-     * against the repository's own pinned tools. **Every plugin's entries are used**, not just the
-     * first - see `BinPath`.
-     */
-    binPaths?: BinPath.Provider;
 }
 /**
- * Identity helper for authoring a plugin with full type-checking - the `defineConfig`/
- * `defineCommand` pattern again, for the same reason. Returns `plugin` unchanged.
- *
- * **A plugin package's entry point exports a *config*, not this**, so that a package is an
- * `.rmanrc` like any other and can carry a second plugin later without changing shape:
+ * **A plugin is whatever a package contributes; a platform is one of the things it can contribute.**
  *
- * ```js
- * // rman-node's entry point
- * import { defineConfig, definePlugin } from 'rman';
- * import publishCommand from './commands/publish.js';
+ * The broad half of the split. `Platform` is a technology and nothing else - required manifest
+ * reader, workspace layout, bin paths, steps, version planning. What is left over is this: an
+ * `init` for whatever the seams do not name yet, and the **declaration** that this plugin provides
+ * platforms.
  *
- * export const nodePlugin = definePlugin({ name: 'rman-node', commands: [publishCommand] });
- * export default defineConfig({ plugins: [nodePlugin] });
- * ```
+ * **`platforms` is a list, and that is not symmetry.** One package can speak for more than one
+ * technology - `maven` and `gradle` are the same toolchain family and a single plugin shipping both
+ * is the natural shape. A singular field would have made the second one a separate package for no
+ * reason.
  *
- * **A module exporting the plugin itself is refused**, with a message saying so. Accepting both
- * would mean telling a plugin from a config at runtime, and `name` is a key either may have - the
- * test would be a guess, and guessing "plugin" registers nothing while reporting success.
+ * A bare `Platform` is accepted anywhere a `Plugin` is, as sugar for `{ name, platforms: [it] }` -
+ * which is what almost every entry is.
  */
-export declare function definePlugin(plugin: RmanPlugin): RmanPlugin;
+export interface Plugin {
+    /** How this plugin is named in messages, and the de-duplication key: registering twice under one
+     *  name is refused. A platform contributed by it keeps its *own* name, which is what a package
+     *  reports as `pkg.platform`. */
+    name: string;
+    /** The technologies this plugin provides, if any. */
+    platforms?: Platform[];
+    /**
+     * Anything this plugin contributes that is not a platform, run once when it is registered.
+     *
+     * **The escape hatch, not the front door.** Commands and publish targets are `.rmanrc` keys
+     * (`commands`, `publishTargets`), so a plugin contributing only those declares them in its own
+     * config and needs no `init` at all. What is left for `init` is whatever the seams do not name
+     * yet, reached through `ctx.app`.
+     *
+     * **It runs inside `Repository.create`**, before any package is known, so `ctx.app.repository`
+     * throws there. Anything wanting the repository belongs in a command's factory instead, which
+     * runs once there is one.
+     */
+    init?(ctx: PluginContext): void | Promise<void>;
+}
 /**
- * Loads every plugin the repository's `.rmanrc "plugins"` declares, in declaration order.
+ * What `Plugin.init` is handed.
  *
- * This is what lets a *package* contribute commands. `.rman/*.mjs` covers one repository's own
- * commands (see `loadCustomCommands`); a plugin covers a whole class of repository - `rman-node`
- * carrying everything that only means something because the repository is a Node one, so rman's
- * core does not have to.
+ * Only the application today. An object rather than a bare parameter so a member added later
+ * breaks nothing already written against it - the same reason `CommandContext` is one, which has
+ * already paid for itself twice.
+ */
+export interface PluginContext {
+    app: RmanApplication;
+}
+/** Whether `value` came from `definePlatform` or `definePlugin`. */
+export declare function isDeclared(value: unknown): boolean;
+/** Declares a **platform** - one technology, whole. Returns it unchanged apart from the mark. */
+export declare function definePlatform(platform: Platform): Platform;
+/** Declares a **plugin** - whatever a package contributes, platforms included. Returns it unchanged
+ *  apart from the mark. */
+export declare function definePlugin(plugin: Plugin): Plugin;
+/** Whether `value` is a platform rather than the broader plugin - `manifestProvider` is what makes
+ *  one, and it is the only required member either type has beyond `name`. */
+export declare function isPlatform(value: Plugin | Platform): value is Platform;
+/**
+ * The platform a package gets when **none** claimed its directory - a repository naming no
+ * platform, or a directory none of the named ones recognized.
  *
- * An entry is a package name, a path, or a plugin object - and a named package's entry point
- * exports a **config**, whose own `plugins` are then loaded the same way (see `loadInto`).
+ * It exists so `Package.platform` need not be optional. `Package.provider` was an empty string for
+ * exactly this case, and every reader had to know that; an object with an empty `name` says the
+ * same thing without a guard, and `pkg.provider === 'node'` - the check CLAUDE.md prescribes -
+ * reads the same either way.
  *
- * Names resolve relative to the repository root's own `node_modules`, the way `extends` resolves -
- * a plugin is the repository's dependency, not rman's.
+ * **Every documented behaviour of "no plugin" survives unchanged**, because the absences are the
+ * behaviour:
  *
- * **A plugin that cannot be loaded throws**, unlike a broken `.rman/*.mjs` file, which is warned
- * about and skipped. The two differ because the consequence does: a skipped local command affects
- * only itself, while a missing plugin silently removes commands the repository is built around -
- * `rman publish` would simply not exist, and "not a known command" sends the reader looking in the
- * wrong place entirely.
+ * - a reader that recognizes nothing -> `Manifest.read` falls through to its own empty manifest,
+ *   exactly as it does when no plugin answers;
+ * - no `getWorkspace` -> a repository naming no plugin has no packages beyond itself, which is the
+ *   boundary working rather than failing (`workspaces` in a `package.json` is npm's idea);
+ * - no `getBinPaths` -> nothing is prepended to a child process's PATH, so the inherited one
+ *   stands on its own rather than being guessed at;
+ * - no `getRunSteps` -> a package's steps come from its `.rmanrc` alone, the core's only source;
+ * - no `versionPlanner` -> `version`/`changed` fail naming the key, rather than releasing a
+ *   plausible but untrue set of packages from a default nobody chose.
  */
-export declare function loadPlugins(rootDir: string, rootConfig: RmanConfig): Promise<LoadedCommand[]>;
+export declare const basePlatform: Platform;