PluginGenerator

Generates a STANDALONE plugin: the composition unit `make:controller`/`make:entity` already generate "by rebound" when no plugin exists yet at their target area (see {@see ControllerGenerator::wireRoute()} / {@see EntityGenerator::wireRepository()}), now available explicitly and on its own — a `#[PluginMetadata]` + `Milpa\Interfaces\Plugin\PluginInterface`, `Milpa\Interfaces\Tooling\ToolProviderInterface` class, ready for a follow-up `make:service`/`make:tool`/`make:controller`/`make:entity`/`make:crud` call (targeting this same plugin name) to wire something into it. F1: the rendered plugin carries {@see \Milpa\DevTools\Make\Markers}' `// {coa:services}` (inside `boot()`) and `// {coa:tools}`/`// {coa:tool-prompts}` (inside `registerTools()`/`getPromptSections()`) anchors from the start — a follow-up composite generator that finds THIS plugin on disk auto-wires its registration at the matching marker instead of only emitting guidance (see {@see ServiceGenerator::wireService()}, {@see ToolGenerator::wireToolProvider()}, and {@see \Milpa\DevTools\Make\MarkerInserter}). It carries `Milpa\Runtime\Http\RouteProviderInterface` and a `// {coa:routes}` anchor too — see below for why that took a second pass. The routes anchor was ORIGINALLY left out on a defensible-sounding argument: `milpa/runtime` is not a `milpa/devtools` dependency (unlike `milpa/core`, where `ToolProviderInterface` lives), so a stub that `implements RouteProviderInterface` cannot be `require`d in THIS package's own test process, only lint-checked. What that reasoning optimized for was the convenience of these tests, and what it cost was paid by every user: a plugin made with `make:plugin` was NOT a valid auto-wire target, so the very next `make:crud` against it found no anchor and printed five `Route` literals for someone to paste by hand. The two most natural commands in a row, and the second one degraded because of a constraint internal to this package. `crud-plugin.runtime.php.stub` had implemented the interface all along and is lint-checked exactly the same way, which is the proof that the constraint was never really binding. Unlike {@see ControllerGenerator}/{@see EntityGenerator}, this generator has no separate "target * plugin" — the plugin IS the artifact being generated, so only `GenerationContext::$name` is read; `GenerationContext::$plugin` is not applicable, and a caller wiring this generator into a CLI command should pass the same value for both (`coa make:plugin <Name>` has a single positional argument). Only a RUNTIME convention exists — see {@see generate()} for why LEGACY throws.

public function __construct(Milpa\DevTools\Make\StubRenderer $renderer = new StubRenderer(), Milpa\DevTools\Make\ConventionDetector $detector = new ConventionDetector()):

Parameters

public function name(): string

The `<what>` token this generator answers to: `'plugin'`.

public function generate(Milpa\DevTools\Make\GenerationContext $context): Milpa\DevTools\Make\GenerationResult

Renders the standalone plugin per the detected/overridden {@see Flavor}.

Parameters

Throws

\RuntimeException When the detected/forced flavor is {@see Flavor::Legacy} — see {@see generateLegacy()}.