Module Api Laravel Package

Product Decisions This Supports

• Build vs. buy for extensibility: This package remains the contract layer for a module/plugin architecture, but the v0.4.0 release moves it from "pure interfaces" to "interfaces plus a DI dependency." That shifts the decision: adopting this contract now also means inheriting slick/di's container abstraction. Contract-first is still the right pattern; the question is whether the contract and the container should be one decision or two.
• Framework/ecosystem bet (now stronger coupling): Committing to slick/module-api is no longer just a commitment to a set of interfaces — v0.4.0 adds slick/di as a hard dependency, so you are also betting on Slick's container. Evaluate against Laravel package conventions (service providers + container bindings) or Symfony bundles, especially if you want to keep your extension contract portable across frameworks.
• Reference design for internal plugins: Still a usable template for defining your own module boundary, and v0.4.0 supplies a concrete design answer worth borrowing: pass the container into console-configuration hooks rather than letting modules construct commands directly. That is a good pattern to copy even if you don't take the dependency (MIT).
• Roadmap constraint mapping: If already on Slick, v0.4.0 changes what third parties can promise: console modules can now resolve dependencies from the container at command-registration time, which unlocks DI-backed CLI commands — but it also means any existing ConsoleModuleInterface implementation is now non-conforming and must be updated.
• Upgrade risk budgeting: The 0.4.0 release is a breaking signature change delivered on a minor bump (legal under 0.x semver, but effectively breaking). Plan for the roadmap assumption that every 0.x release may break; the interface you pin is not the interface you'll get next quarter.
• Use cases it plausibly serves: first-party feature modules, white-label/customer-specific extensions, DI-driven console command modules, and a lightweight third-party add-on surface — all contingent on a live Slick codebase.

Honest framing unchanged, and slightly worse: still near-zero public traction, and the release notes for v0.4.0 open by announcing "the v0.3.1 release" — a documentation-hygiene miss. PM value is as a pattern and a contract, not as a feature delivery.

When to Consider This Package

Consider it when:

• You are already standardized on the Slick framework and need to author, review, or version modules against a stable contract — and you accept slick/di as part of that contract.
• You need console modules that create commands through the dependency container; v0.4.0's ContainerInterface parameter is the only way to do that against this API.
• You want a documented boundary so multiple teams or external contributors can extend the same system without touching core internals.
• You're doing architecture due-diligence and want a small, readable example of a modular PHP contract layer with a container hand-off.

Look elsewhere when:

• Your stack is Laravel or Symfony — use native service-provider or bundle conventions. v0.4.0 makes this clearer: you would be importing a foreign container abstraction for no benefit.
• You need runtime capabilities: module discovery, autoloading scaffolding, config merging. The console container hook is a parameter, not wiring — you still build discovery and registration yourself.
• You need a dependency-free contract. That property is gone as of v0.4.0; if it mattered to you (e.g., you wanted modules to contract against nothing but the API), vendor the interfaces and drop the container parameter or swap in PSR-11.
• Active maintenance, security response, or support matters. Signals remain weak: no visible adopters, no community, single maintainer, and release notes that misname their own version. Treat as vendor-and-pin.
• You have existing ConsoleModuleInterface implementations and no budget to update them — upgrading to 0.4.0 is a required code change, not a drop-in.

How to Pitch It (Stakeholders)

To executives: Small, MIT-licensed contract library — no licensing cost and no commercial lock-in. Two things changed with v0.4.0: it now pulls in Slick's dependency-injection package, so it is no longer a self-contained set of interfaces; and it introduces a breaking change to the console-module contract (existing modules must be updated). The strategic recommendation stands: borrow the pattern or vendor the interfaces rather than adopting the ecosystem by default. Cost of switching later remains low, but "zero dependencies" is no longer a true statement in the deck.

To engineering: v0.4.0 passes a ContainerInterface (from the newly added slick/di dependency) into ConsoleModuleInterface::configureConsole(), enabling container-resolved command creation — genuinely useful for CLI modules. Treat it as breaking: every existing implementation of that method must be updated to accept the new argument. Also assume 0.x minor bumps can break generally, so pin exactly, review the changelog before each upgrade, and keep the diff surface small. Note the package is no longer interfaces-only — you now inherit a transitive DI dependency's release cadence. If we're not on Slick, copy the interfaces (and optionally the container hand-off pattern) into our own namespace and own them; the design is good, the supply chain is not.