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

package/core/plugin-loader.js

@@ -1,102 +1,27 @@
-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';
+import { isPlatform } from './interfaces/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`.
+ * **Puts one contribution onto an application** - a technology, or a plugin - and the only place
+ * that knows how.
  *
- * **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:
+ * **Exported because a spec must not reimplement it.** A fixture writing the registrations 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.
  *
- * - **`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.
+ * **Neither hook is called here, and that is deliberate.** `afterInitApplication` and
+ * `afterInitRepository` belong to `Repository.create`, which knows when each stage is reached and
+ * can await them; this is a synchronous call a fixture makes while building an application.
  */
+/* **Two registries and no normalization, which is what the split bought.** A bare `Platform` used
+ * to be wrapped in `{ name, platforms: [entry] }` so that everything downstream dealt in one shape
+ * - and that shape was `Plugin.platforms`, which is gone: `platforms` is a config key now, so a
+ * package shipping a technology declares it there and nothing has to invent a plugin around it.
+ * What is left is a question with two honest answers, asked once. */
 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);
+    if (isPlatform(entry)) {
+        app.platforms.add(entry);
         /**
          * **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
@@ -106,118 +31,12 @@ export function registerPlugin(app, entry) {
          * 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;
+        if (entry.versionPlanner)
+            app.versionPlanner = entry.versionPlanner;
+        return;
     }
-    return declared;
+    app.plugins.add(entry);
 }
-/**
- * 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) {

package/index.d.ts

@@ -29,9 +29,9 @@
  * Type-only, so the emitted module is empty - imported for what it declares, not for what it does.
  * Pinned in `docs-api.spec.ts`, which imports only from this file.
  */
-import './plugins/node/augmentation/rman.augmentation.js';
+import './builtins/platforms/node/augmentation/rmanrc.augmentation.js';
 import type { RmanConfig as CommandDeclaration } from './interfaces/rman-config.interface.js';
-export { defineConfig } from './core/config.js';
+export { defineConfig } from './interfaces/rman-config.interface.js';
 /**
  * **A config value written as a function**, and the scope it is handed. Exported because a config
  * author could not name either: `interpolateConfig` calls a function wherever a `${{ }}` could
@@ -42,25 +42,26 @@ export { defineConfig } from './core/config.js';
  * `value`, i.e. what an expression sees. Not to be confused with `RunStepContext`, which is what a
  * step gets, later, with a working directory and a `runBin`.
  */
-export type { ConfigScope, ConfigValue, ConfigValueContext, FileScope, PackageScope, Resolved, ResolvedConfig, } from './core/config.js';
-export type { CommandContext, CustomCommand } from './core/custom-command.js';
-export { defineCommand } from './core/custom-command.js';
+export type { CommandContext, CustomCommand } from './core/interfaces/custom-command.js';
+export { defineCommand } from './core/interfaces/custom-command.js';
+export type { ConfigScope, ConfigValueContext, FileScope, PackageScope } from './interfaces/config-scope.interface.js';
+export type { ConfigValue, Resolved, ResolvedConfig } from './interfaces/rman-config.interface.js';
 /** Both the shape and the registry: `const m: Manifest` and `Manifest.read(dir)` - merged onto one
  *  name so a plugin can augment it the way it augments `SystemInfo`. */
 export { RmanApplication } from './core/application.js';
 /** The manifest seam, grouped on a plugin as `Plugin.manifestProvider`: where a package's name and
  *  version are written, what it declares, and how it is numbered and stamped. The core has none -
  *  `package.json` is npm's answer, and belongs to the `node` built-in. */
-export type { ManifestProvider } from './core/manifest.js';
-export { Manifest } from './core/manifest.js';
-export { Package } from './core/package.js';
+export { Package } from './core/classes/package.js';
+export type { ManifestProvider } from './core/interfaces/manifest.js';
+export { Manifest } from './core/interfaces/manifest.js';
 /** The publish seam: where a package's artifact ships. The core brings `docker` (nobody's
  *  ecosystem); npm's target is the `node` built-in's, and any other technology's is its own plugin's. */
-export { declaredTargets, type PublishTarget, shipsTo, targetsOf, unknownTargets } from './core/publish-target.js';
-export { Registry } from './core/registry.js';
-export { Repository } from './core/repository.js';
-export type { RunConditionFn, RunStepContext, RunStepFn, RunStepValue } from './core/run-step.js';
-export { Service, type ServiceFactory, type ServiceMap } from './core/service.js';
+export { Registry } from './core/classes/registry.js';
+export { Repository } from './core/classes/repository.js';
+export { Service, type ServiceFactory, type ServiceMap } from './core/classes/service.js';
+export { declaredTargets, type PublishTarget, shipsTo, targetsOf, unknownTargets, } from './core/interfaces/publish-target.js';
+export type { RunConditionFn, RunStepContext, RunStepFn, RunStepValue } from './core/interfaces/run-step.js';
 /**
  * **`Platform` is one technology, whole**; **`Plugin` is whatever a package contributes**, platforms
  * among them.
@@ -74,18 +75,18 @@ export { Service, type ServiceFactory, type ServiceMap } from './core/service.js
  * rman 1.x plugin was `{ name, init }` and so is a 2.x plugin contributing nothing but an `init` -
  * no shape test can tell them apart.
  */
-export { basePlatform, definePlatform, definePlugin, isPlatform, type Platform, type Plugin, type PluginContext, } from './core/plugin.js';
-export type { ChangeKind } from './core/version-scheme.js';
+export type { ChangeKind } from './core/classes/version-scheme.js';
+export { basePlatform, definePlatform, definePlugin, isPlatform, type Platform, type Plugin, type PluginContext, } from './core/interfaces/plugin.js';
 /** The numbering seam. `VersionScheme` is abstract - `highestVersion`/`highestBump`/`smallestBump`
  *  are implemented from the members around them, so a scheme states only what it must and still
  *  overrides any of the three. `SemverScheme` is exported to subclass rather than restate. */
-export { assertOneScheme, SemverScheme, semverScheme, VersionScheme } from './core/version-scheme.js';
+export { assertOneScheme, SemverScheme, semverScheme, VersionScheme } from './core/classes/version-scheme.js';
 /** The workspace seam: how a repository's packages are found. A plugin contributes a provider
  *  (see `Plugin.workspace`); the core has none, so `workspaces` is npm's idea and belongs to the
  *  `node` built-in. */
 /** `Workspace.Layout`, `Workspace.Provider`, `Workspace.addProvider`, `Workspace.resolve`,
  *  `Workspace.findRoot` - one namespace, so a plugin can augment it. */
-export { Workspace } from './core/workspace.js';
+export { Workspace } from './core/classes/workspace.js';
 /**
  * **How a command is declared** - the same API the built-ins use, so a plugin's command is declared
  * rather than built: options as data (checked for typos), positionals named against the command
@@ -142,21 +143,21 @@ export { formatDuration, type ProgressItem, ProgressPanel, type ProgressStatus,
  *  does, and so must a publish target deciding whether a version needs its own dist-tag. Exported
  *  because that second caller lives in a plugin. */
 /**
- * **The `node` built-in's own surface.** It ships inside rman rather than as `rman-node`, so its
- * services and target are named from here - a repository asks for the technology with
- * `plugins: ['node']` (or lets detection find it) and never constructs any of this by hand.
+ * **The `node` preset's own surface.** It ships inside rman rather than as `rman-node`, so its
+ * services and target are named from here - a repository gets the technology from
+ * `DEFAULT_PRESETS`, or names it with `extends: "rman:node"`, and never constructs any of this by
+ * hand.
  *
  * Its `.rmanrc` *keys* arrive separately, through the bare import at the top of this file - see
  * there for why that import is not tidiness.
  */
-export { BUILTIN_PLUGINS, builtinPluginNames, isBuiltinPlugin } from './plugins/builtins.js';
-export type { NodeConfigKeys, RmanNodeConfig } from './plugins/node/node-config.interface.js';
-export { NPM_TARGET, NpmPublishTarget } from './plugins/node/npm-publish-target.js';
-export { CiService } from './plugins/node/services/ci.service.js';
-export { CleanService } from './plugins/node/services/clean.service.js';
-export { PublishService } from './plugins/node/services/publish.service.js';
-export { NodeVersionPlanService } from './plugins/node/services/version-plan.service.js';
-export type { ParsedWorkspaceRange } from './plugins/node/utils/workspace-range.js';
+export type { NodeConfigKeys, RmanNodeConfig } from './builtins/platforms/node/node-config.interface.js';
+export { CiService } from './builtins/platforms/node/services/ci.service.js';
+export { CleanService } from './builtins/platforms/node/services/clean.service.js';
+export { PublishService } from './builtins/platforms/node/services/publish.service.js';
+export { NodeVersionPlanService } from './builtins/platforms/node/services/version-plan.service.js';
+export type { ParsedWorkspaceRange } from './builtins/platforms/node/utils/workspace-range.js';
+export { NPM_TARGET, NpmPublishTarget } from './builtins/publish-targets/npm/npm-publish-target.js';
 export { isCalendarVersion } from './utils/release-version.js';
 export type { RunBinOptions, RunBinResult } from './utils/run-bin.js';
 export { runBin } from './utils/run-bin.js';

package/index.js

@@ -29,44 +29,34 @@
  * Type-only, so the emitted module is empty - imported for what it declares, not for what it does.
  * Pinned in `docs-api.spec.ts`, which imports only from this file.
  */
-import './plugins/node/augmentation/rman.augmentation.js';
-export { defineConfig } from './core/config.js';
-export { defineCommand } from './core/custom-command.js';
+import './builtins/platforms/node/augmentation/rmanrc.augmentation.js';
+export { defineConfig } from './interfaces/rman-config.interface.js';
+export { defineCommand } from './core/interfaces/custom-command.js';
 /** Both the shape and the registry: `const m: Manifest` and `Manifest.read(dir)` - merged onto one
  *  name so a plugin can augment it the way it augments `SystemInfo`. */
 export { RmanApplication } from './core/application.js';
-export { Manifest } from './core/manifest.js';
-export { Package } from './core/package.js';
+/** The manifest seam, grouped on a plugin as `Plugin.manifestProvider`: where a package's name and
+ *  version are written, what it declares, and how it is numbered and stamped. The core has none -
+ *  `package.json` is npm's answer, and belongs to the `node` built-in. */
+export { Package } from './core/classes/package.js';
+export { Manifest } from './core/interfaces/manifest.js';
 /** The publish seam: where a package's artifact ships. The core brings `docker` (nobody's
  *  ecosystem); npm's target is the `node` built-in's, and any other technology's is its own plugin's. */
-export { declaredTargets, shipsTo, targetsOf, unknownTargets } from './core/publish-target.js';
-export { Registry } from './core/registry.js';
-export { Repository } from './core/repository.js';
-export { Service } from './core/service.js';
-/**
- * **`Platform` is one technology, whole**; **`Plugin` is whatever a package contributes**, platforms
- * among them.
- *
- * A platform says how its packages are recognized and written, where they live, what goes on a
- * child's PATH and how its releases are planned - `manifestProvider` is what makes one, and it is
- * required. A plugin carries `platforms` and an `init` for anything the seams do not name yet; a
- * bare `Platform` is accepted wherever a `Plugin` is, as sugar for the plugin that provides only it.
- *
- * **Both must be declared through their factory.** `loadPlugins` checks for the mark, because an
- * rman 1.x plugin was `{ name, init }` and so is a 2.x plugin contributing nothing but an `init` -
- * no shape test can tell them apart.
- */
-export { basePlatform, definePlatform, definePlugin, isPlatform, } from './core/plugin.js';
+export { Registry } from './core/classes/registry.js';
+export { Repository } from './core/classes/repository.js';
+export { Service } from './core/classes/service.js';
+export { declaredTargets, shipsTo, targetsOf, unknownTargets, } from './core/interfaces/publish-target.js';
+export { basePlatform, definePlatform, definePlugin, isPlatform, } from './core/interfaces/plugin.js';
 /** The numbering seam. `VersionScheme` is abstract - `highestVersion`/`highestBump`/`smallestBump`
  *  are implemented from the members around them, so a scheme states only what it must and still
  *  overrides any of the three. `SemverScheme` is exported to subclass rather than restate. */
-export { assertOneScheme, SemverScheme, semverScheme, VersionScheme } from './core/version-scheme.js';
+export { assertOneScheme, SemverScheme, semverScheme, VersionScheme } from './core/classes/version-scheme.js';
 /** The workspace seam: how a repository's packages are found. A plugin contributes a provider
  *  (see `Plugin.workspace`); the core has none, so `workspaces` is npm's idea and belongs to the
  *  `node` built-in. */
 /** `Workspace.Layout`, `Workspace.Provider`, `Workspace.addProvider`, `Workspace.resolve`,
  *  `Workspace.findRoot` - one namespace, so a plugin can augment it. */
-export { Workspace } from './core/workspace.js';
+export { Workspace } from './core/classes/workspace.js';
 /**
  * **How a command is declared** - the same API the built-ins use, so a plugin's command is declared
  * rather than built: options as data (checked for typos), positionals named against the command
@@ -102,27 +92,11 @@ export { applyFromRootOption, applyPackageFilterOptions, filterPackages, fromRoo
 /** The live panel `run`/`build`/`clean` print - a plugin's per-package command looks like the rest
  *  of rman instead of like a script someone bolted on. */
 export { formatDuration, ProgressPanel, } from './utils/progress-panel.js';
-/** Version stamping helpers a `Plugin.stampVersion` can delegate to - the quoted-constant
- *  pattern most languages share, and the OCI Dockerfile label (which `version` stamps itself, since
- *  the label's value is by specification the package's version). */
-/** A calendar version's time part (`2026.9.15-1430`) is a semver *prerelease identifier* by
- *  construction, so anything asking "is this a preview?" has to rule it out first - `github-release`
- *  does, and so must a publish target deciding whether a version needs its own dist-tag. Exported
- *  because that second caller lives in a plugin. */
-/**
- * **The `node` built-in's own surface.** It ships inside rman rather than as `rman-node`, so its
- * services and target are named from here - a repository asks for the technology with
- * `plugins: ['node']` (or lets detection find it) and never constructs any of this by hand.
- *
- * Its `.rmanrc` *keys* arrive separately, through the bare import at the top of this file - see
- * there for why that import is not tidiness.
- */
-export { BUILTIN_PLUGINS, builtinPluginNames, isBuiltinPlugin } from './plugins/builtins.js';
-export { NPM_TARGET, NpmPublishTarget } from './plugins/node/npm-publish-target.js';
-export { CiService } from './plugins/node/services/ci.service.js';
-export { CleanService } from './plugins/node/services/clean.service.js';
-export { PublishService } from './plugins/node/services/publish.service.js';
-export { NodeVersionPlanService } from './plugins/node/services/version-plan.service.js';
+export { CiService } from './builtins/platforms/node/services/ci.service.js';
+export { CleanService } from './builtins/platforms/node/services/clean.service.js';
+export { PublishService } from './builtins/platforms/node/services/publish.service.js';
+export { NodeVersionPlanService } from './builtins/platforms/node/services/version-plan.service.js';
+export { NPM_TARGET, NpmPublishTarget } from './builtins/publish-targets/npm/npm-publish-target.js';
 export { isCalendarVersion } from './utils/release-version.js';
 export { runBin } from './utils/run-bin.js';
 export { OCI_VERSION_LABEL, stampVersionConstant, stampVersionLabel } from './utils/version-stamp.js';