Plugin Manager Laravel Package

Product Decisions This Supports

• Extensibility strategy: build a plugin surface or ship a fixed API. Adopting a plugin manager is a product decision, not a library choice — it commits the roadmap to making the integration layer a first-class platform concern. Instead of "every customer-specific integration becomes an engineering ticket," it becomes "someone ships a plugin."
• Ecosystem and marketplace roadmap. A plugin manager is the substrate for a partner directory, paid add-ons, or an integration catalog. If monetized extensions are on a 12–24 month horizon, the loader, manifest format, and version-compatibility rules need to exist before the first partner conversation — not after.
• Decoupling release cadence from customer customization. For hosting, billing, or control-panel style products where individual tenants need bespoke behavior, per-plugin enablement lets those changes ship on their own schedule instead of inflating the core release train.
• White-label and self-hosted SKUs from one codebase. Per-deployment plugin enablement is often the cheapest route to a second revenue line without branching the product.
• Feature flags vs. plugins — a scoping decision worth forcing early. Teams frequently reach for a plugin manager when what they actually need is staged rollout. This evaluation forces the honest question: is the requirement third-party code execution (plugins) or internal gating (flags)?
• Buy vs. build on the boot path. A plugin loader sits in application bootstrap. Whoever owns it owns a piece of startup criticality — an ownership decision that should be made explicitly rather than inherited by default.
• Security posture for third-party code. Committing here means committing to manifest validation, allowlisting, and filesystem permissions as ongoing product obligations, not one-time setup.

When to Consider This Package

Consider it when:

• You are on Symfony (or genuinely comfortable running Symfony DI semantics inside your app). The package is described as a Symfony plugins manager; the vendor namespace and design point that way. A pure-Laravel adoption means fighting the grain of Laravel's own package discovery.
• You need runtime discovery and activation, not just compile-time wiring — enabling or disabling plugins per environment or per tenant without a redeploy.
• You need inter-plugin dependency awareness — ordering, prerequisites, version constraints — which naive service-provider auto-discovery does not provide.
• You have an internal sponsor and can fund a spike. The project reads as extracted from a vendor's own control-panel product: a reasonable provenance signal that it solves a real problem, but also a sign it was shaped around their requirements.
• You can validate the plugin contract against your own tenancy model in a time-boxed effort before committing.

Look elsewhere when:

• Zero stars, zero dependents, no community vetting. You would be the first external adopter. Treat it as "unproven internal library," not "package."
• You need a support contract, SLA, or predictable release cadence. Bus factor is unknown, and a plugin manager is exactly the dependency whose abandonment is expensive because it is entangled with boot.
• You are Laravel-native. Prefer native service-provider auto-discovery plus explicit contracts, nwidart/laravel-modules for module separation, or stancl/tenancy if per-tenant enablement is the real requirement. Symfony's native bundle system covers the Symfony case without a third-party layer.
• You only need flags, gating, or a handful of first-party integrations. A plugin manager is per-request overhead you will pay forever; three well-placed interfaces are cheaper.
• You cannot tolerate arbitrary third-party code in-process. This package will not give you sandboxing. If untrusted code execution is the requirement, that is an isolation and process-boundary problem, not a plugin-manager problem.

How to Pitch It (Stakeholders)

To executives: A plugin manager is how we stop paying engineering for every customer-specific integration. It is the difference between a product and a platform — partners extend us instead of us extending ourselves — and it is the prerequisite for any add-on marketplace or white-label SKU revenue. The decision on the table is not "should we adopt this library"; it is "do we want an extension surface at all." If yes, this package is a candidate implementation to validate, not a purchase to approve. Framed that way, a two-week spike is cheap relative to the strategic question it answers.

To engineering: This is a Symfony-oriented plugin manager offering runtime discovery, manifest-driven registration, and inter-plugin dependency handling — the genuinely tedious parts, and the parts that live on application bootstrap. It has no stars and no dependents, so we treat it as untrusted third-party code regardless of provenance: read it, spike it, pin it exactly. Two-week evaluation against our own plugin contract. If it does not map cleanly to our stack's native provider model, we take the design ideas — manifest schema, lifecycle states, dependency ordering — and build a thin loader in-house rather than inherit an unmaintained boot-path dependency. Either way we own the loader: vendor or mirror the source, add per-plugin try/catch at registration, strict manifest schema validation, an enforced host-version constraint, cycle detection on plugin dependencies, and a disable-all kill switch that requires no deploy.

Recommendation: Do not adopt as a dependency on the strength of the repository alone. Run a scoped spike (≈1 engineer, 2 weeks) to answer two questions: does the plugin contract fit our tenancy model, and is the code of a quality we would accept on the boot path? Proceed as a dependency only if both are yes; otherwise use it as a reference design and own the loader ourselves.