/** * plugin command — manage a PACK-SUPPORTING tool's project-local * npm-installed extension packs (fit/sim checks, recipes, scenarios). * * The pack ops are mounted UNDER each pack-supporting tool primary — * `opensip fit plugin {add|list|remove|sync}` (domain pre-bound to `fit`), * `opensip sim plugin {…}` (domain `sim`). There is no top-level * `opensip plugin` command, and no `--domain`/`--type` flag: the tool the * subcommand hangs off of IS the domain. Whole Tool plugins (platform * subcommands) are installed/uninstalled with `opensip tools …`, never here. * * Layout (no user-global plugin dir): * * /opensip-cli/.runtime/plugins// * ├── package.json — host package; "dependencies" is the * │ plugin install state for this domain * └── node_modules/ — npm-installed plugin packages * * /opensip-cli.config.yml * plugins: * fit: * - "@org/fitness-checks" — declares which installed packages * discovery should LOAD. Required; * discovery does not auto-load every * installed package (silent loads * would surprise users). * * ` plugin add ` is the one-step install: writes the package to * .runtime/plugins//node_modules AND adds it to plugins. * in the project config. After: `opensip fit` loads it on next run. * * ` plugin remove ` is the inverse: removes from node_modules AND * deletes from plugins.. * * ` plugin list` walks .runtime/plugins//node_modules + the * config to show what's installed and what's currently loaded. * * ` plugin sync` is the post-clone bootstrap: reads plugins. from * the config and `npm install`s everything declared. Used by CI and * by users who clone a repo with custom plugins. * * Module layout * ------------- * - This file owns the `plugin {list,add,remove,sync}` command bodies. * - `plugin/config-edit.ts` — YAML round-trip edits to plugins.. * - `plugin/domain-resolution.ts` — TOOL_DOMAIN + the pure validation * logic that routes a spec to a domain (no install). * - `plugin/host-dir.ts` — host package.json creation + installed- * package introspection (incl. peer-dependency auto-install). */ import { type PluginLayout, type ToolProvenance } from '@opensip-cli/core'; import { editPluginList } from './plugin-host-ops.js'; import type { PluginResult } from '@opensip-cli/contracts'; /** * Test-only export for the YAML-driven config edit so unit tests can * exercise the round-trip behaviour without spawning npm. Intentionally * not part of the public CLI API surface. */ export declare const __test: { editPluginList: typeof editPluginList; }; export declare function pluginList(cwd?: string, layouts?: readonly PluginLayout[], toolProvenance?: readonly ToolProvenance[]): Promise; /** * Install a pack AND add it to the project config in one step, scoped to the * caller's bound `domain` (the pack-supporting tool the subcommand hangs off * of — `fit`/`sim`). Whole Tool plugins are NOT installable here; use * `opensip tools install`. * * Without the config update, the package wouldn't get loaded — making * "install" alone always incomplete. Single-step is the only sensible * default. */ export declare function pluginAdd(packageName: string | undefined, cwd?: string, domainOverride?: string, layouts?: readonly PluginLayout[]): Promise; export declare function pluginRemove(packageName: string | undefined, cwd?: string, domainOverride?: string, layouts?: readonly PluginLayout[]): Promise; /** * Install every plugin declared in `plugins.` for a given * domain (or all domains when none specified). Idempotent — re-running * after `git pull` updates the install state. * * The post-clone story: a developer clones a repo with declared * plugins, runs `opensip plugin sync`, and the * .runtime/plugins//node_modules trees are populated. Without * this, the first `opensip fit` would warn about every declared * plugin being uninstalled. */ export declare function pluginSync(cwd?: string, domainOverride?: string, layouts?: readonly PluginLayout[]): Promise; //# sourceMappingURL=plugin.d.ts.map