rman 2.0.0-beta.2 → 2.0.0-beta.4

package/core/core-services.d.ts

@@ -1,14 +0,0 @@
-import type { RmanApplication } from './application.js';
-/**
- * Every service the core brings, registered as an application is built.
- *
- * **Factories rather than instances**, so nothing is constructed until something asks: `rman info`
- * has no business building the changelog or release services, and services reach each other through
- * the application, so resolving at call time is also what keeps that from being a construction
- * cycle.
- *
- * Here rather than inside `RmanApplication` so the composition list is one readable file, and so
- * the application itself imports no service - only this does. A plugin adds its own the same way,
- * from its own package, with `app.setService`.
- */
-export declare function registerCoreServices(app: RmanApplication): void;

package/core/core-services.js

@@ -1,30 +0,0 @@
-import { ChangelogService } from '../services/changelog.service.js';
-import { DockerPublishService } from '../services/docker-publish.service.js';
-import { ExecService } from '../services/exec.service.js';
-import { GithubReleaseService } from '../services/github-release.service.js';
-import { ImportService } from '../services/import.service.js';
-import { ListService } from '../services/list.service.js';
-import { RunService } from '../services/run.service.js';
-import { VersionService } from '../services/version.service.js';
-/**
- * Every service the core brings, registered as an application is built.
- *
- * **Factories rather than instances**, so nothing is constructed until something asks: `rman info`
- * has no business building the changelog or release services, and services reach each other through
- * the application, so resolving at call time is also what keeps that from being a construction
- * cycle.
- *
- * Here rather than inside `RmanApplication` so the composition list is one readable file, and so
- * the application itself imports no service - only this does. A plugin adds its own the same way,
- * from its own package, with `app.setService`.
- */
-export function registerCoreServices(app) {
-    app.setService('changelog', a => new ChangelogService(a));
-    app.setService('dockerPublish', a => new DockerPublishService(a));
-    app.setService('githubRelease', a => new GithubReleaseService(a));
-    app.setService('exec', a => new ExecService(a));
-    app.setService('import', a => new ImportService(a));
-    app.setService('list', a => new ListService(a));
-    app.setService('run', a => new RunService(a));
-    app.setService('version', a => new VersionService(a));
-}

package/core/core-targets.d.ts

@@ -1,14 +0,0 @@
-import type { RmanApplication } from './application.js';
-/**
- * Every publish target the core brings, registered as an application is built - `registerCoreServices`
- * for the other half of what a fresh application starts with.
- *
- * Exactly one today, and that is the point: `docker` is the target that belongs to no ecosystem, so
- * it is the only one the core can honestly ship. `npm` arrives with the `node` built-in, and a Cargo or
- * Maven target would arrive from its own plugin the same way.
- *
- * A separate file from `core-services.ts` rather than a second call inside it: a target is not a
- * service (it is a contribution summed with others, not one replaceable answer), and a function
- * called `registerCoreServices` that also registered targets would have to be read to be believed.
- */
-export declare function registerCoreTargets(app: RmanApplication): void;

package/core/core-targets.js

@@ -1,16 +0,0 @@
-import { dockerPublishTarget } from '../targets/docker.target.js';
-/**
- * Every publish target the core brings, registered as an application is built - `registerCoreServices`
- * for the other half of what a fresh application starts with.
- *
- * Exactly one today, and that is the point: `docker` is the target that belongs to no ecosystem, so
- * it is the only one the core can honestly ship. `npm` arrives with the `node` built-in, and a Cargo or
- * Maven target would arrive from its own plugin the same way.
- *
- * A separate file from `core-services.ts` rather than a second call inside it: a target is not a
- * service (it is a contribution summed with others, not one replaceable answer), and a function
- * called `registerCoreServices` that also registered targets would have to be read to be believed.
- */
-export function registerCoreTargets(app) {
-    app.publishTargets.add(dockerPublishTarget);
-}

package/core/extends-config.d.ts

@@ -1,35 +0,0 @@
-import type { RmanConfig } from '../interfaces/rman-config.interface.js';
-/** The key naming configs to inherit from, the way eslint and tsconfig spell it. */
-export declare const EXTENDS_KEY = "extends";
-/**
- * Resolves `config`'s own `extends` into it: every named config is loaded, merged in declaration
- * order, and `config`'s own keys land on top. Returns a new object with no `extends` left in it.
- *
- * The point is a shared package - `extends: "@panates/rman-monorepo"` - so a repository declares
- * its house rules once instead of restating them. `+key` is what makes that liveable (see
- * `mergeConfig`): without it, adding one step to a base's list means copying the list.
- *
- * `from` is the file the `extends` was written in, and everything resolves relative to **it**: a
- * bare specifier through that file's own `node_modules`, a relative path against its directory.
- * Resolving from rman's own location instead would look in rman's dependencies, where a
- * repository's shared config has no reason to be.
- *
- * `seen` carries the chain being resolved, so a config that extends its way back to itself is
- * reported rather than recursed into forever.
- */
-export declare function resolveExtends(config: RmanConfig, from: string, seen?: string[]): Promise<RmanConfig>;
-/**
- * **Refuses the keys a `"[selector]"` block cannot carry** - each for its own reason, and the
- * reason is the same shape every time: a selector block is typed as a whole `RmanConfig`, so any
- * key looks valid there, and one that can never be read is a config that quietly does nothing.
- * That is worse than one that will not load.
- *
- * - **`extends`** is a statement about the *file*, not about the packages a selector happens to
- *   name, and it belongs at the top level where it would actually be resolved.
- * - **`platform` and `name`** are what the selector is derived *from*, so a glob block setting
- *   either would need its own answer in order to be matched. See below; `"[/]"` is exempt.
- *
- * Called on every config form a directory can hold and on every `extends` base, so the file in the
- * message is the one the line was written in.
- */
-export declare function assertSelectorBlocks(config: RmanConfig, file: string): void;

package/core/extends-config.js

@@ -1,129 +0,0 @@
-import fs from 'node:fs';
-import path from 'node:path';
-import * as yaml from 'js-yaml';
-import { isSelectorKey, parseSelector } from './config.js';
-import { loadConfigModule } from './load-config-module.js';
-import { mergeConfig } from './merge-config.js';
-import { resolveConfigTarget } from './resolve-target.js';
-/** The key naming configs to inherit from, the way eslint and tsconfig spell it. */
-export const EXTENDS_KEY = 'extends';
-/**
- * Resolves `config`'s own `extends` into it: every named config is loaded, merged in declaration
- * order, and `config`'s own keys land on top. Returns a new object with no `extends` left in it.
- *
- * The point is a shared package - `extends: "@panates/rman-monorepo"` - so a repository declares
- * its house rules once instead of restating them. `+key` is what makes that liveable (see
- * `mergeConfig`): without it, adding one step to a base's list means copying the list.
- *
- * `from` is the file the `extends` was written in, and everything resolves relative to **it**: a
- * bare specifier through that file's own `node_modules`, a relative path against its directory.
- * Resolving from rman's own location instead would look in rman's dependencies, where a
- * repository's shared config has no reason to be.
- *
- * `seen` carries the chain being resolved, so a config that extends its way back to itself is
- * reported rather than recursed into forever.
- */
-export async function resolveExtends(config, from, seen = []) {
-    const declared = config[EXTENDS_KEY];
-    if (declared === undefined)
-        return config;
-    const targets = Array.isArray(declared) ? declared : [declared];
-    for (const target of targets) {
-        if (typeof target !== 'string' || !target.trim()) {
-            throw new Error(`"extends" in "${from}" must be a config name or path, or an array of them`);
-        }
-    }
-    const base = {};
-    for (const target of targets) {
-        const file = resolveConfigTarget(target, from, EXTENDS_KEY);
-        if (seen.includes(file)) {
-            throw new Error(`"extends" forms a cycle: ${[...seen, file].map(f => path.basename(f)).join(' -> ')}`);
-        }
-        const loaded = await loadConfigFile(file);
-        assertSelectorBlocks(loaded, file);
-        // Recursive: a shared config may itself be built on another.
-        mergeConfig(base, await resolveExtends(loaded, file, [...seen, file]), file);
-    }
-    const own = { ...config };
-    delete own[EXTENDS_KEY];
-    return mergeConfig(base, own);
-}
-/**
- * **Refuses the keys a `"[selector]"` block cannot carry** - each for its own reason, and the
- * reason is the same shape every time: a selector block is typed as a whole `RmanConfig`, so any
- * key looks valid there, and one that can never be read is a config that quietly does nothing.
- * That is worse than one that will not load.
- *
- * - **`extends`** is a statement about the *file*, not about the packages a selector happens to
- *   name, and it belongs at the top level where it would actually be resolved.
- * - **`platform` and `name`** are what the selector is derived *from*, so a glob block setting
- *   either would need its own answer in order to be matched. See below; `"[/]"` is exempt.
- *
- * Called on every config form a directory can hold and on every `extends` base, so the file in the
- * message is the one the line was written in.
- */
-export function assertSelectorBlocks(config, file) {
-    for (const [key, value] of Object.entries(config)) {
-        if (!isSelectorKey(key) || !value || typeof value !== 'object')
-            continue;
-        if (EXTENDS_KEY in value) {
-            throw new Error(`"${key}" in "${file}" cannot use "extends" - it belongs at the top level, where it is a ` +
-                `statement about this config rather than about the packages the selector names.`);
-        }
-        /**
-         * **The two keys a selector cannot carry, because the selector is downstream of them.**
-         *
-         * A `"[glob]"` matches `Package.selector`, which comes from `name` - and which package a
-         * directory even holds comes from `platform`. Both are read from the *unmarked* cascade, while
-         * the packages are still being found, so a glob block setting either would need its own answer
-         * in order to be matched at all. Typed as a whole `RmanConfig`, both look valid there and both
-         * would simply never be read.
-         *
-         * `"[/]"` is exempt and keeps working: the root is addressed structurally - its directory *is*
-         * the repository root - so a root block needs no selector and is applied during the walk.
-         */
-        if (parseSelector(key).scope === 'root')
-            continue;
-        for (const identity of IDENTITY_KEYS) {
-            if (identity in value) {
-                throw new Error(`"${key}" in "${file}" cannot set "${identity}" - a glob matches a package's selector, ` +
-                    `and "${identity}" is what the selector is derived from, so the block could never be ` +
-                    `matched in order to apply it. Write it unmarked, in the package's own ".rmanrc", or ` +
-                    `under "[/]" for the root package.`);
-            }
-        }
-    }
-}
-/**
- * Loads one resolved target. YAML and JSON are read directly; anything else goes through
- * `loadConfigModule`, so a shared config can be a `defineConfig` module with real logic in it.
- *
- * **Through that function rather than a bare `await import()`, which is what this used to do.**
- * The two are not equivalent under an ESM loader hook: a `.cjs` base came back as an empty object,
- * and an empty object is a valid config, so it contributed nothing and said nothing. See there for
- * the measurement - the same file loaded correctly when it was a *directory's* own `.rmanrc.cjs`,
- * because that path always used the careful loader.
- */
-async function loadConfigFile(file) {
-    const ext = path.extname(file);
-    if (ext === '.yml' || ext === '.yaml') {
-        const obj = yaml.load(fs.readFileSync(file, 'utf-8'));
-        return asConfig(obj, file);
-    }
-    if (ext === '.json')
-        return asConfig(JSON.parse(fs.readFileSync(file, 'utf-8')), file);
-    return asConfig(await loadConfigModule(file), file);
-}
-function asConfig(value, file) {
-    if (!value || typeof value !== 'object' || Array.isArray(value)) {
-        throw new Error(`"${file}" does not export an rman config object`);
-    }
-    const config = { ...value };
-    // Editor tooling only - meaningless once merged, and `additionalProperties` would reject it
-    // wherever it ended up.
-    delete config.$schema;
-    return config;
-}
-/** The keys that decide *what a package is* and *what addresses it*, read from the unmarked
- *  cascade before any package exists - see `assertSelectorBlocks`. */
-const IDENTITY_KEYS = ['platform', 'name'];

package/core/load-config-module.d.ts

@@ -1,28 +0,0 @@
-/**
- * Loads a config module - a `.rmanrc.cjs`/`.mjs`/`.js`, or an `extends` target that is one.
- *
- * **`require()` first, and that is not an optimization.** A CommonJS module's `module.exports` is
- * more reliably observed this way than through dynamic `import()`'s CJS-interop synthesis, which
- * some ESM loader hooks - ts-node/swc-node-style transpilers registered via `--import` - can
- * short-circuit into an **empty object**. `require()` throws `ERR_REQUIRE_ESM` for a genuinely-ESM
- * file (`.mjs`, or `.js` under `"type": "module"`), and only then does this fall back to
- * `import()`, the one case that actually needs it.
- *
- * Either path can hand back an ES module namespace rather than a plain object - Node's
- * `require(esm)` support does this too, not just `import()` - so `.default` is preferred whenever
- * present.
- *
- * **It lives here because `extends` needs it too, and did not have it.** A directory's own
- * `.rmanrc.cjs` went through this while `extends-config.ts` used a bare `await import()`, so the
- * *same file* loaded correctly as a directory's config and came back empty when another config
- * named it - and an empty object is a valid config, so nothing was reported. Measured under mocha:
- * a base declaring `"[*]": { version: { stamp: ['build'] } }`, reached by
- * `extends: './base.cjs'`, contributed nothing; the identical fixture with `base.json` contributed
- * normally, and the same `.cjs` worked from the CLI, where no loader hook is registered.
- *
- * `createRequire` is based on this module's own URL rather than on the config file. That is right
- * here and *not* right for resolving a bare specifier - see `resolveConfigTarget`, which is based
- * on the config file so a package name resolves through the repository's `node_modules` rather than
- * rman's own. By the time a file reaches this function it is already an absolute path.
- */
-export declare function loadConfigModule(file: string): Promise<any>;

package/core/load-config-module.js

@@ -1,42 +0,0 @@
-import { createRequire } from 'node:module';
-import { pathToFileURL } from 'node:url';
-/**
- * Loads a config module - a `.rmanrc.cjs`/`.mjs`/`.js`, or an `extends` target that is one.
- *
- * **`require()` first, and that is not an optimization.** A CommonJS module's `module.exports` is
- * more reliably observed this way than through dynamic `import()`'s CJS-interop synthesis, which
- * some ESM loader hooks - ts-node/swc-node-style transpilers registered via `--import` - can
- * short-circuit into an **empty object**. `require()` throws `ERR_REQUIRE_ESM` for a genuinely-ESM
- * file (`.mjs`, or `.js` under `"type": "module"`), and only then does this fall back to
- * `import()`, the one case that actually needs it.
- *
- * Either path can hand back an ES module namespace rather than a plain object - Node's
- * `require(esm)` support does this too, not just `import()` - so `.default` is preferred whenever
- * present.
- *
- * **It lives here because `extends` needs it too, and did not have it.** A directory's own
- * `.rmanrc.cjs` went through this while `extends-config.ts` used a bare `await import()`, so the
- * *same file* loaded correctly as a directory's config and came back empty when another config
- * named it - and an empty object is a valid config, so nothing was reported. Measured under mocha:
- * a base declaring `"[*]": { version: { stamp: ['build'] } }`, reached by
- * `extends: './base.cjs'`, contributed nothing; the identical fixture with `base.json` contributed
- * normally, and the same `.cjs` worked from the CLI, where no loader hook is registered.
- *
- * `createRequire` is based on this module's own URL rather than on the config file. That is right
- * here and *not* right for resolving a bare specifier - see `resolveConfigTarget`, which is based
- * on the config file so a package name resolves through the repository's `node_modules` rather than
- * rman's own. By the time a file reaches this function it is already an absolute path.
- */
-export async function loadConfigModule(file) {
-    let mod;
-    try {
-        mod = requireConfigModule(file);
-    }
-    catch (e) {
-        if (e?.code !== 'ERR_REQUIRE_ESM')
-            throw e;
-        mod = await import(pathToFileURL(file).href);
-    }
-    return mod?.default ?? mod;
-}
-const requireConfigModule = createRequire(import.meta.url);

package/core/workspace.d.ts

@@ -1,119 +0,0 @@
-import type { RmanApplication } from './application.js';
-import type { Platform } from './plugin.js';
-/**
- * How a repository is laid out, and who decides.
- *
- * A namespace for the same reason `Manifest` is one: it is what a plugin can *augment*
- * (`declare module 'rman' { namespace Workspace { ... } }`), so whatever this seam grows later
- * arrives as a member here rather than as another top-level export.
- */
-export declare namespace Workspace {
-    /**
-     * **Where one directory's own child packages are** - the directories immediately below it that
-     * hold a package, as absolute paths. `undefined` for "this is not a directory I recognize".
-     *
-     * **A provider answers for one directory, not for the repository**, and that is the whole
-     * correction. It used to be `(root) => { root, packageDirs }`: asked once, at the top, by the
-     * first platform that recognized it - so in a polyglot repository the technology listed first in
-     * `plugins` decided which directories were packages *at all*. Measured, and documented as a known
-     * limitation for a year: a `Cargo.toml`-only package was simply not found until a provider that
-     * looks for both was listed first.
-     *
-     * Asked per directory, each platform only ever answers about its own packages - which is all a
-     * platform knows - and the recursion is the core's (see `walk`). A Cargo workspace nested inside
-     * a Node monorepo is then just a node in the tree whose children came from a different platform.
-     *
-     * **Children, not descendants.** A provider returning the whole subtree would have to know what
-     * the platforms below it consider a package; returning one level means it never has to. npm's
-     * `workspaces` globs are already one level by construction (`deep: 0`).
-     *
-     * Still directories rather than `Package` objects, for the reason it always was: discovery runs
-     * before any package exists, so a provider returning packages would make discovery the owner of
-     * identity too. A path is also unique by construction, where a name is only unique if the
-     * ecosystem says so.
-     */
-    type Provider = (dir: string) => string[] | undefined;
-    /**
-     * One directory in the walk's result: which technology claimed it, and what sits below it.
-     *
-     * A plain tree rather than `Package`s, keeping the line `Provider` draws: `Repository.create`
-     * turns this into packages, so identity stays with the manifest provider and discovery stays
-     * with this one.
-     */
-    interface Node {
-        /** Absolute path to the directory. */
-        dirname: string;
-        /** The technology that claimed it - `basePlatform` when none did, so a reader needs no guard. */
-        platform: Platform;
-        /** The nodes for the package directories directly below it, in the order the platform gave
-         *  them. Empty for a leaf. */
-        children: Node[];
-    }
-    /**
-     * What a directory's `.rmanrc "platform"` resolves to, when it declares one - `undefined` when
-     * it says nothing, so the walk falls back to the guess.
-     *
-     * **A callback rather than config knowledge in here**, which keeps this namespace answering one
-     * question. Reading a directory's cascaded config, deciding that a declared name has to be
-     * loaded, and refusing one that cannot be, are all the repository's business; where the packages
-     * are is this one's. `Repository.create` supplies it - and it is also the seam a spec uses to
-     * drive the declaration path without writing a config file.
-     */
-    type DeclaredPlatform = (dir: string) => Promise<Platform | undefined>;
-    /**
-     * **The walk**: descend from `rootDir`, asking each directory's own technology where its children
-     * are, and repeating for each answer.
-     *
-     * One step, applied recursively:
-     *
-     * 1. take the directory's **declared** platform if it has one, and otherwise the first registered
-     *    platform whose manifest provider recognizes it (`app.platformFor`, `basePlatform` if none);
-     * 2. ask **that** platform's `getWorkspace` for the directories below it holding packages;
-     * 3. do the same for each of them.
-     *
-     * **A declaration wins, and is then held to it.** A platform named for a directory it does not
-     * recognize is a statement that is simply untrue, and the failure it would otherwise become is
-     * invisible: the manifest reads as nothing, so the package is named after its directory at
-     * `0.0.0` and the repository looks like it works. The error names the directory, the platform and
-     * the file that platform looked for.
-     *
-     * The root node always exists - a repository is a package whatever its technology - so this never
-     * returns `undefined`. A repository nobody recognizes is a root with no children, which is the
-     * single-package answer arrived at rather than guessed.
-     *
-     * **A directory is visited once.** A provider may legitimately name a directory another one
-     * already claimed (two globs overlapping, a symlinked package), and a provider naming an ancestor
-     * would otherwise recurse forever. First visit wins, so a package sits where it was first found.
-     *
-     * `deep` bounds the descent for the same reason `findRoot` bounds its climb: a provider computing
-     * paths rather than reading them can produce a chain that never ends, and a guessed depth is
-     * better than a hang with nothing printed.
-     */
-    function walk(app: RmanApplication, rootDir: string, options?: {
-        deep?: number;
-        declared?: DeclaredPlatform;
-    }): Promise<Node>;
-    /** Every node below `node`, depth-first, excluding `node` itself - the flat list `Repository`
-     *  reports as its packages, since the root is not one of its own members. */
-    function flatten(node: Node): Node[];
-    /**
-     * Where the repository starts, decided **without knowing anything about any ecosystem** - it has
-     * to be, because the plugins that do know are named in the config file this walk is looking for.
-     *
-     * Walking up from `from`, stopping after a directory holding `.git`, the root is:
-     *
-     * 1. the **outermost** directory in that chain holding an `.rmanrc*` - outermost, because a
-     *    *package* may have its own `.rmanrc` (that is a supported thing), and from inside such a
-     *    package the nearest one is the package's, not the repository's;
-     * 2. otherwise the `.git` directory itself, the ordinary meaning of "repository root";
-     * 3. otherwise `from`, which is all that is left to go on.
-     *
-     * **What "outermost" costs**, since the two cases genuinely conflict and only one can win: a
-     * self-contained project nested inside a larger git repository *and sharing its `.git`* resolves
-     * to the outer root, not to itself (measured). That is the same repository by any definition git
-     * recognizes, so it is the defensible answer - and a nested project with a `.git` of its own is
-     * found correctly, because the walk stops there before the outer `.rmanrc` is ever seen (also
-     * measured). A per-package `.rmanrc` is the common case and it is the one served.
-     */
-    function findRoot(from: string, deep?: number): string;
-}

package/core/workspace.js

@@ -1,124 +0,0 @@
-import fs from 'node:fs';
-import path from 'node:path';
-/**
- * How a repository is laid out, and who decides.
- *
- * A namespace for the same reason `Manifest` is one: it is what a plugin can *augment*
- * (`declare module 'rman' { namespace Workspace { ... } }`), so whatever this seam grows later
- * arrives as a member here rather than as another top-level export.
- */
-export var Workspace;
-(function (Workspace) {
-    /**
-     * **The walk**: descend from `rootDir`, asking each directory's own technology where its children
-     * are, and repeating for each answer.
-     *
-     * One step, applied recursively:
-     *
-     * 1. take the directory's **declared** platform if it has one, and otherwise the first registered
-     *    platform whose manifest provider recognizes it (`app.platformFor`, `basePlatform` if none);
-     * 2. ask **that** platform's `getWorkspace` for the directories below it holding packages;
-     * 3. do the same for each of them.
-     *
-     * **A declaration wins, and is then held to it.** A platform named for a directory it does not
-     * recognize is a statement that is simply untrue, and the failure it would otherwise become is
-     * invisible: the manifest reads as nothing, so the package is named after its directory at
-     * `0.0.0` and the repository looks like it works. The error names the directory, the platform and
-     * the file that platform looked for.
-     *
-     * The root node always exists - a repository is a package whatever its technology - so this never
-     * returns `undefined`. A repository nobody recognizes is a root with no children, which is the
-     * single-package answer arrived at rather than guessed.
-     *
-     * **A directory is visited once.** A provider may legitimately name a directory another one
-     * already claimed (two globs overlapping, a symlinked package), and a provider naming an ancestor
-     * would otherwise recurse forever. First visit wins, so a package sits where it was first found.
-     *
-     * `deep` bounds the descent for the same reason `findRoot` bounds its climb: a provider computing
-     * paths rather than reading them can produce a chain that never ends, and a guessed depth is
-     * better than a hang with nothing printed.
-     */
-    async function walk(app, rootDir, options) {
-        const visited = new Set();
-        const descend = async (dir, remaining) => {
-            const resolved = path.resolve(dir);
-            visited.add(resolved);
-            const declared = await options?.declared?.(resolved);
-            if (declared && !declared.manifestProvider.read(resolved)) {
-                throw new Error(`"${resolved}" declares \`platform: '${declared.name}'\`, and that platform does not ` +
-                    `recognize it - it looks for "${declared.manifestProvider.fileName}". Either the ` +
-                    `directory is not a ${declared.name} package, or the declaration belongs one level down.`);
-            }
-            const platform = declared ?? app.platformFor(resolved);
-            const node = { dirname: resolved, platform, children: [] };
-            if (remaining <= 0)
-                return node;
-            /**
-             * **Its own platform is asked, and nobody else.** A platform that did not claim the directory
-             * has no standing to say what is under it - that was the old first-wins rule, one level up.
-             * `basePlatform` has no `getWorkspace`, so a directory no technology claimed has no children,
-             * which is the documented behaviour of a repository naming no plugin.
-             */
-            for (const child of platform.getWorkspace?.(resolved) ?? []) {
-                const childDir = path.resolve(child);
-                if (visited.has(childDir))
-                    continue;
-                node.children.push(await descend(childDir, remaining - 1));
-            }
-            return node;
-        };
-        return descend(rootDir, options?.deep ?? 10);
-    }
-    Workspace.walk = walk;
-    /** Every node below `node`, depth-first, excluding `node` itself - the flat list `Repository`
-     *  reports as its packages, since the root is not one of its own members. */
-    function flatten(node) {
-        return node.children.flatMap(child => [child, ...flatten(child)]);
-    }
-    Workspace.flatten = flatten;
-    /**
-     * Where the repository starts, decided **without knowing anything about any ecosystem** - it has
-     * to be, because the plugins that do know are named in the config file this walk is looking for.
-     *
-     * Walking up from `from`, stopping after a directory holding `.git`, the root is:
-     *
-     * 1. the **outermost** directory in that chain holding an `.rmanrc*` - outermost, because a
-     *    *package* may have its own `.rmanrc` (that is a supported thing), and from inside such a
-     *    package the nearest one is the package's, not the repository's;
-     * 2. otherwise the `.git` directory itself, the ordinary meaning of "repository root";
-     * 3. otherwise `from`, which is all that is left to go on.
-     *
-     * **What "outermost" costs**, since the two cases genuinely conflict and only one can win: a
-     * self-contained project nested inside a larger git repository *and sharing its `.git`* resolves
-     * to the outer root, not to itself (measured). That is the same repository by any definition git
-     * recognizes, so it is the defensible answer - and a nested project with a `.git` of its own is
-     * found correctly, because the walk stops there before the outer `.rmanrc` is ever seen (also
-     * measured). A per-package `.rmanrc` is the common case and it is the one served.
-     */
-    function findRoot(from, deep = 10) {
-        const chain = [];
-        let dir = path.resolve(from);
-        let remaining = deep;
-        while (remaining-- >= 0 && fs.existsSync(dir)) {
-            chain.push(dir);
-            if (fs.existsSync(path.join(dir, '.git')))
-                break;
-            const parent = path.resolve(dir, '..');
-            if (parent === dir)
-                break;
-            dir = parent;
-        }
-        const withConfig = chain.filter(hasRmanConfig);
-        if (withConfig.length)
-            return withConfig[withConfig.length - 1];
-        const gitRoot = chain.find(d => fs.existsSync(path.join(d, '.git')));
-        return gitRoot ?? path.resolve(from);
-    }
-    Workspace.findRoot = findRoot;
-    /** Every file form a `.rmanrc` comes in - `package.json#rman` is deliberately *not* one of them
-     *  here: it would make the root question npm-shaped again. */
-    const CONFIG_FILES = ['.rmanrc', '.rmanrc.yml', '.rmanrc.cjs', '.rmanrc.mjs', '.rmanrc.js'];
-    function hasRmanConfig(dir) {
-        return CONFIG_FILES.some(name => fs.existsSync(path.join(dir, name)));
-    }
-})(Workspace || (Workspace = {}));

package/plugins/builtins.d.ts

@@ -1,44 +0,0 @@
-import type { Platform } from '../core/plugin.js';
-import type { RmanConfig } from '../interfaces/rman-config.interface.js';
-/**
- * **The plugins rman ships in the box, by the name a config calls them.**
- *
- * `plugins: ['node']` is the whole of it - no new key, because there is no new concept. A
- * repository was always able to say which technologies it holds; this is that same statement with
- * a name instead of an instance, which is the form a YAML config and a zero-config repository both
- * need.
- *
- * **Bundled is not the same as always on, and keeping those apart is the point.** Nothing an entry
- * contributes exists until a repository names it or detection finds it, so the core still assumes
- * no ecosystem and `rman clean` is still `Unknown argument` in a repository that is not a Node one.
- * What changed is only where the code is shipped from - one install instead of two, which is what
- * `extends: 'rman-node'` was costing every Node repository for a benefit that belonged to polyglot
- * ones.
- *
- * The key is `Plugin.name`, so what a config writes is what `${{ pkg.provider }}` reads back.
- *
- * **A published package is still not one of these.** `plugins: ['rman-node']` names a package, whose
- * config reaches a repository through `extends`; it is refused, saying so. The two are different
- * statements and a built-in name is neither of them - it is the plugin itself, called by name.
- */
-export declare const BUILTIN_PLUGINS: Record<string, Builtin>;
-/**
- * One built-in, in the two halves that must not be the same call.
- *
- * **`plugin` answers questions; `contribute` changes the run.** Detection asks a platform whether a
- * directory is its own, which has to be possible without registering anything - and registering is
- * what `contribute` does: it hands over commands, publish targets and (for `node`) an augmentation
- * that rewrites the core's `SystemInfo` in place. One call for both would have "is this a Node
- * repository?" print npm's tooling in a Cargo one, which is exactly the line between *bundled* and
- * *on*.
- */
-export interface Builtin {
-    /** The platform itself, for asking - constructed, registered nowhere, with no side effect. */
-    platform: () => Platform;
-    /** Everything this built-in adds to a repository that asked for it. */
-    contribute: () => RmanConfig;
-}
-/** Whether `name` is one rman ships - the check `plugins` makes before treating a string as a glob. */
-export declare function isBuiltinPlugin(name: string): boolean;
-/** The built-in names, for an error message that has to list what a repository could have meant. */
-export declare function builtinPluginNames(): string[];

package/plugins/builtins.js

@@ -1,33 +0,0 @@
-import { nodeBuiltin, nodePlatform } from './node/index.js';
-/**
- * **The plugins rman ships in the box, by the name a config calls them.**
- *
- * `plugins: ['node']` is the whole of it - no new key, because there is no new concept. A
- * repository was always able to say which technologies it holds; this is that same statement with
- * a name instead of an instance, which is the form a YAML config and a zero-config repository both
- * need.
- *
- * **Bundled is not the same as always on, and keeping those apart is the point.** Nothing an entry
- * contributes exists until a repository names it or detection finds it, so the core still assumes
- * no ecosystem and `rman clean` is still `Unknown argument` in a repository that is not a Node one.
- * What changed is only where the code is shipped from - one install instead of two, which is what
- * `extends: 'rman-node'` was costing every Node repository for a benefit that belonged to polyglot
- * ones.
- *
- * The key is `Plugin.name`, so what a config writes is what `${{ pkg.provider }}` reads back.
- *
- * **A published package is still not one of these.** `plugins: ['rman-node']` names a package, whose
- * config reaches a repository through `extends`; it is refused, saying so. The two are different
- * statements and a built-in name is neither of them - it is the plugin itself, called by name.
- */
-export const BUILTIN_PLUGINS = {
-    node: { platform: () => nodePlatform, contribute: nodeBuiltin },
-};
-/** Whether `name` is one rman ships - the check `plugins` makes before treating a string as a glob. */
-export function isBuiltinPlugin(name) {
-    return Object.hasOwn(BUILTIN_PLUGINS, name);
-}
-/** The built-in names, for an error message that has to list what a repository could have meant. */
-export function builtinPluginNames() {
-    return Object.keys(BUILTIN_PLUGINS).sort();
-}