Extension Laravel Package

Product Decisions This Supports

• Build vs. buy on runtime modularity. The decision this package actually forces is not "adopt orchestra/extension or not" — it's "do we build our own discovery, activation-state, migration-ordering, and boot-order registry, or do we adopt someone else's?" Evaluating it produces a concrete baseline to price that build against, even if the answer is "neither, use native package discovery plus a table we own."
• Modular monolith vs. service sprawl. If the roadmap contains features that must ship, enable, or disable independently — per customer, per tier, per deployment — this component demonstrates the full lifecycle loop: extension:detect → activate → migrate → publish. That capability is what makes a modular monolith a defensible alternative to premature microservices. The PM takeaway is whether we need lifecycle runtime control or merely code organization; only the former justifies this dependency.
• SKU, tier, and entitlement strategy. Activation state is one mechanism for gating features by segment, license, or on-prem contract. This forces a decision between three operational postures that look similar on a roadmap slide but differ enormously in support cost: config-flag gating (cheap, code-owned), installed-package gating (deploy-owned), and admin-toggleable activation records (customer-owned, and therefore a support surface).
• On-prem and admin-operated deployment models. If we intend to let customer admins or internal ops toggle modules themselves, that changes release cadence, QA scope, and how we price the offering. This package makes that a costable product option rather than a hand-wave — while surfacing that activation state becomes a runtime dependency of the UI, which means it must be shipped through deploys, never hand-toggled in production.
• Partner/plugin ecosystem direction. Any marketplace or third-party integration story needs discovery and lifecycle state as table stakes. Evaluating this clarifies how much of that foundation is genuinely solved versus still bespoke — and draws a hard line: this is a management layer, not a security boundary. No sandboxing, no versioned host→extension API contract, no signed registry. Any roadmap item implying third-party extension safety must be scoped as separate work; do not let the word "extension" imply containment. | Decision | What this package informs | PM action | |---|---|---| | Modularity mechanism | Custom registry vs. adopt vs. native | Write the decision record before it gets re-litigated | | Feature gating model | Config flag vs. package state vs. admin toggle | Pick the support posture, then the tech | | Extension ecosystem | Foundation vs. greenfield | Scope the security boundary separately | | Ownership model | Adopt-and-follow vs. fork-and-own | Budget headcount, not just a version pin |

When to Consider This Package

Consider it when:

• The application is already on Orchestra Platform. In that case the component is likely present transitively via orchestra/foundation, and the question shifts from "adopt?" to "pin and own deliberately?" — a materially cheaper decision. Verify with composer require orchestra/extension --dry-run before designing anything; constraint failures cost an hour and settle the matter.
• Runtime lifecycle management is a genuine requirement — detect, activate, migrate, publish, with extension-to-extension dependencies declared in orchestra.json and deterministic boot ordering. If we would otherwise write that orchestration ourselves, this is a legitimate reference implementation to price against.
• Administrator-driven module toggling is a real product requirement, not a nice-to-have: multi-tenant deployments, on-prem installs, or licensed module packaging.
• We are prepared to treat the dependency as internally owned — forked, vendored, patched, and upgraded on our schedule. Given minimal stars, zero listed dependents, a single-maintainer profile, and a last visible milestone at Laravel 8, that is the only honest adoption posture.

Look elsewhere when:

• We are on modern standalone Laravel (9+). Coupling cost dominates. nwidart/laravel-modules for scaffolding, Laravel's native package discovery for registration, and a small application-owned activation table cover most of the value with a maintainable footprint.
• The need is code organization, not runtime state changes. Modular directories are a Composer and service-provider problem. If a feature ships to every customer and never toggles, a plain package with a service provider is cheaper in every dimension — no manifest, no activation record, no migration orchestration, no drift.
• We require a broadly adopted, actively maintained dependency with visible release cadence, security process, or commercial support. The signals here don't support that.
• Per-tenant activation is the goal but we'd be retrofitting it. The stock factory persists one global activation set; scoping activated() per tenant means binding a custom Factory implementation early. Late retrofits after extensions are written against global state are painful.
• We can't staff the upgrade path. Assume we own it.

Note the escape hatch worth recording in the decision record: native package discovery plus an enabled_extensions table we control, with per-package migrate --force in the deploy script, gets roughly 80% of the value with a clear ownership story.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version. We evaluated orchestra/extension, a lifecycle component for building toggleable modules on Laravel. It solves a real product capability — shipping features that can be discovered, enabled, migrated, and disabled at runtime without a redeploy — which is the foundation for tiered SKUs, on-prem module licensing, and any future partner ecosystem. But it is not a safe strategic dependency as-is: minimal adoption signals, a single maintainer, and a Laravel 8-era ceiling mean adopting it means owning it. Recommendation: do not adopt as a dependency. Do use it as the reference spec for a small, application-owned equivalent, and decide the feature-gating and ownership questions now rather than next quarter.

For engineering — what we're asking for. A one-day spike, not a quarter. Verify the Composer dry-run resolves; if it fails on PHP or illuminate/* constraints, stop. Otherwise stand up a single throwaway extension (extensions/acme/hello/ with composer.json, orchestra.json, and one logging service provider) and run detect → activate → migrate → publish. If the log line appears, we've proved detection, activation, provider registration, and migration orchestration. If it doesn't, we've bought certainty cheaply. Either way the output is a spec, not a merge.

The honest trade-off to state plainly. We are choosing a smaller owned surface over a larger borrowed one. That costs us a build and ongoing headcount; it buys deterministic ownership, a modern framework baseline, and no ambiguity about who fixes a broken activation at 2am. Three risks we must design around regardless of path: "active but not autoloaded" (check autoload before the manager), cache staleness after deploy (make invalidation an explicit release-checklist item), and silent partial activation (chain activate → migrate → publish → verify in one ExtensionManager call and fail loudly).

What we are explicitly not buying. A security boundary, a versioned host→extension contract, or a plugin marketplace. If any roadmap item assumes third-party code runs safely inside this model, that is separate, unscoped work.