rman 2.0.0-beta.2 → 2.0.0-beta.3

package/plugins/detect.d.ts

@@ -1,78 +0,0 @@
-/**
- * **Which platform a repository looks like, when it has not said.**
- *
- * The 2.0 split made every Node repository write a config file before `rman clean` would run, and
- * the cost of that landed on exactly the repositories the split was not for. This is the other half
- * of the fix: a repository that declares no technology gets the one its own files already imply.
- *
- * **The core does not know what any repository looks like, and must not.** It asks the *platforms*
- * - `manifestProvider.read(dir)` has always meant "is this directory one of mine?", so there is no
- * new seam and no list of filenames anywhere in `core/`. This file listed `package.json` for one
- * commit, which is the same mistake as the hardcoded `['npm']` publish default that
- * `PublishTarget.claims` exists to have replaced: true of npm, written in a place that speaks for
- * every ecosystem, and invisible while only one platform ships.
- *
- * The platforms it can ask are the ones it has, which are the built-ins - by construction, not by
- * choice: a third-party platform arrives through `plugins` or `extends`, and a repository that
- * wrote either has declared its technology, so detection never runs for it.
- *
- * **Only ever consulted when nothing was declared** - see `Repository.create`, which checks both the
- * config and the application. That boundary is the whole safety of it, because registering a
- * platform changes *which directories are packages at all* (`Workspace.resolve` takes the first
- * provider that answers), so guessing on top of an explicit statement could quietly change what
- * `rman list` reports.
- *
- * **It is announced, not silent.** A guess the reader cannot see is one they cannot correct.
- */
-export interface DetectedBuiltin {
-    /** The built-in's name - what `plugins: [...]` would have said. */
-    name: string;
-    /** The file that gave it away, for the message - the platform's own `manifestFile`. */
-    because: string;
-}
-/**
- * Marks a config whose `plugins` was **detected rather than declared**, so the one caller that
- * should say so can tell.
- *
- * A non-enumerable symbol, the way `ORIGINS` and `PREVIOUS_VALUES` already carry bookkeeping: it
- * travels with the config through `mergeConfig`, `JSON.stringify` and `rman config` without any of
- * them knowing it is there, and `expect`'s `toEqual` compares symbol properties - so a plain
- * property would turn every config-shape spec into a diff about this.
- *
- * The alternative was re-deriving the answer where the message is printed, which means reading the
- * config twice and two places that can disagree about what "declared" means.
- */
-export declare const DETECTED_BUILTIN: unique symbol;
-/** What detection put on `config`, if anything. */
-export declare function detectedBuiltinOf(config: object): DetectedBuiltin | undefined;
-/**
- * The first built-in platform that claims `dir`, or `undefined` for a repository none of them
- * recognizes - which is the honest answer, not a default.
- *
- * **First match, in declaration order**, the same rule `Manifest.read` and `Workspace.resolve`
- * already follow, so a repository two platforms both recognize resolves the same way here as it
- * will once they are loaded.
- *
- * Memoized per directory: this is asked once per directory per package and each ask reads the disk.
- * Nothing here writes, so the answer cannot change under a run in any way that matters.
- *
- * **Async only because `builtins.js` is imported dynamically, and that is a cycle rather than a
- * style** - the same one `expandBuiltinPlugins` in `config.ts` already documents, reached from the
- * other side. A built-in pulls in its commands and services; one of those services extends a core
- * service, and the core's own module graph comes back through here:
- *
- * ```
- * services/version-plan.service -> core/application -> core/core-services
- *   -> services/github-release.service -> core/repository -> plugins/detect
- *   -> plugins/builtins -> plugins/node/index -> plugins/node/node.platform
- *   -> plugins/node/services/version-plan.service  (extends the first, still initialising)
- * ```
- *
- * **Measured, and the suite could not see it**: the *built* CLI died on every command with
- * `ReferenceError: Cannot access 'VersionPlanService' before initialization`, while `npm test`
- * passed - mocha resolves `src` through `tsconfig-test.json`'s `paths`, which is a different module
- * graph and happens to reach the two in the other order. `npm run smoke` is what looks now.
- */
-export declare function detectBuiltin(dir: string): Promise<DetectedBuiltin | undefined>;
-/** Forgets what was detected - for a spec that writes a fixture, detects, then writes another. */
-export declare function clearDetectionCache(): void;

package/plugins/detect.js

@@ -1,70 +0,0 @@
-import path from 'node:path';
-/**
- * Marks a config whose `plugins` was **detected rather than declared**, so the one caller that
- * should say so can tell.
- *
- * A non-enumerable symbol, the way `ORIGINS` and `PREVIOUS_VALUES` already carry bookkeeping: it
- * travels with the config through `mergeConfig`, `JSON.stringify` and `rman config` without any of
- * them knowing it is there, and `expect`'s `toEqual` compares symbol properties - so a plain
- * property would turn every config-shape spec into a diff about this.
- *
- * The alternative was re-deriving the answer where the message is printed, which means reading the
- * config twice and two places that can disagree about what "declared" means.
- */
-export const DETECTED_BUILTIN = Symbol('rman.detectedBuiltin');
-/** What detection put on `config`, if anything. */
-export function detectedBuiltinOf(config) {
-    return config[DETECTED_BUILTIN];
-}
-/**
- * The first built-in platform that claims `dir`, or `undefined` for a repository none of them
- * recognizes - which is the honest answer, not a default.
- *
- * **First match, in declaration order**, the same rule `Manifest.read` and `Workspace.resolve`
- * already follow, so a repository two platforms both recognize resolves the same way here as it
- * will once they are loaded.
- *
- * Memoized per directory: this is asked once per directory per package and each ask reads the disk.
- * Nothing here writes, so the answer cannot change under a run in any way that matters.
- *
- * **Async only because `builtins.js` is imported dynamically, and that is a cycle rather than a
- * style** - the same one `expandBuiltinPlugins` in `config.ts` already documents, reached from the
- * other side. A built-in pulls in its commands and services; one of those services extends a core
- * service, and the core's own module graph comes back through here:
- *
- * ```
- * services/version-plan.service -> core/application -> core/core-services
- *   -> services/github-release.service -> core/repository -> plugins/detect
- *   -> plugins/builtins -> plugins/node/index -> plugins/node/node.platform
- *   -> plugins/node/services/version-plan.service  (extends the first, still initialising)
- * ```
- *
- * **Measured, and the suite could not see it**: the *built* CLI died on every command with
- * `ReferenceError: Cannot access 'VersionPlanService' before initialization`, while `npm test`
- * passed - mocha resolves `src` through `tsconfig-test.json`'s `paths`, which is a different module
- * graph and happens to reach the two in the other order. `npm run smoke` is what looks now.
- */
-export async function detectBuiltin(dir) {
-    const resolved = path.resolve(dir);
-    if (cache.has(resolved))
-        return cache.get(resolved);
-    const { BUILTIN_PLUGINS } = await import('./builtins.js');
-    let found;
-    for (const [name, builtin] of Object.entries(BUILTIN_PLUGINS)) {
-        const platform = builtin.platform();
-        /** `read` is the question. Its answer is thrown away - the manifest is read again for real once
-         *  the platform is registered, and reading it twice is cheaper than keeping a half-built
-         *  package around to decide whether it should exist. */
-        if (platform.manifestProvider.read(resolved)) {
-            found = { name, because: platform.manifestProvider.fileName };
-            break;
-        }
-    }
-    cache.set(resolved, found);
-    return found;
-}
-/** Forgets what was detected - for a spec that writes a fixture, detects, then writes another. */
-export function clearDetectionCache() {
-    cache.clear();
-}
-const cache = new Map();

package/plugins/node/index.d.ts

@@ -1,29 +0,0 @@
-import './augmentation/rman.augmentation.js';
-import { type Platform } from '../../core/plugin.js';
-import type { RmanConfig } from '../../interfaces/rman-config.interface.js';
-/**
- * **The `node` built-in, as the config it contributes** - its technology, its two commands and its
- * publish target, which is exactly what `extends: 'rman-node'` used to deliver.
- *
- * A *config* rather than a bare `Plugin`, and that distinction is the whole reason `plugins: ['node']`
- * can replace an `extends`: a technology alone would bring the manifest reader and leave `rman clean`
- * an unknown argument.
- *
- * **A function, so nothing here happens until a repository asks for it.** `augmentSystemInfo()`
- * mutates the core's own `SystemInfo` in place, so calling it at import time would have `rman info`
- * report npm's tooling in a Cargo repository that never named this built-in - which is the shape of
- * "bundled" quietly becoming "always on". The type-only augmentation above is imported eagerly
- * because a type costs nothing at runtime and a config author's editor wants it either way.
- */
-/**
- * **The platform itself, for asking.** Detection puts a directory to every built-in's platform -
- * `manifestProvider.read(dir)` is already "is this one of mine?" - and that question must be
- * answerable without turning anything on. Constructed once: a `NodePlatform` holds no state and two
- * of them answering differently is not a thing worth allowing.
- *
- * **Declared, like any other platform.** `loadPlugins` refuses anything that did not come through
- * `definePlatform`/`definePlugin`, and a built-in is registered by the same loader as everything
- * else - the mark is not something being inside rman excuses.
- */
-export declare const nodePlatform: Platform;
-export declare function nodeBuiltin(): RmanConfig;

package/plugins/node/index.js

@@ -1,40 +0,0 @@
-import './augmentation/rman.augmentation.js';
-import { definePlatform } from '../../core/plugin.js';
-import { augmentSystemInfo } from './augmentation/system-info.augmentation.js';
-import ciCommand from './commands/ci.command.js';
-import cleanCommand from './commands/clean.command.js';
-import { NodePlatform } from './node.platform.js';
-import { NpmPublishTarget } from './npm-publish-target.js';
-/**
- * **The `node` built-in, as the config it contributes** - its technology, its two commands and its
- * publish target, which is exactly what `extends: 'rman-node'` used to deliver.
- *
- * A *config* rather than a bare `Plugin`, and that distinction is the whole reason `plugins: ['node']`
- * can replace an `extends`: a technology alone would bring the manifest reader and leave `rman clean`
- * an unknown argument.
- *
- * **A function, so nothing here happens until a repository asks for it.** `augmentSystemInfo()`
- * mutates the core's own `SystemInfo` in place, so calling it at import time would have `rman info`
- * report npm's tooling in a Cargo repository that never named this built-in - which is the shape of
- * "bundled" quietly becoming "always on". The type-only augmentation above is imported eagerly
- * because a type costs nothing at runtime and a config author's editor wants it either way.
- */
-/**
- * **The platform itself, for asking.** Detection puts a directory to every built-in's platform -
- * `manifestProvider.read(dir)` is already "is this one of mine?" - and that question must be
- * answerable without turning anything on. Constructed once: a `NodePlatform` holds no state and two
- * of them answering differently is not a thing worth allowing.
- *
- * **Declared, like any other platform.** `loadPlugins` refuses anything that did not come through
- * `definePlatform`/`definePlugin`, and a built-in is registered by the same loader as everything
- * else - the mark is not something being inside rman excuses.
- */
-export const nodePlatform = definePlatform(new NodePlatform());
-export function nodeBuiltin() {
-    augmentSystemInfo();
-    return {
-        plugins: [nodePlatform],
-        commands: [ciCommand, cleanCommand],
-        publishTargets: [new NpmPublishTarget()],
-    };
-}