Support Providers Laravel Package

Product Decisions This Supports

• Build vs. buy for the "module plumbing" layer. If the roadmap contains an extension marketplace, customer-installable add-ons, tenant-enabled feature packs, or a modular monolith, someone has to own provider discovery, deferred registration, config merging, and command wiring. This package is a prebuilt candidate for exactly that layer — it lets the team buy plumbing instead of inventing a provider manifest. The decision it informs is narrow and infrastructural, not customer-facing.
• Whether to pursue a modular/extension architecture at all. The package is only valuable as an accelerant to that roadmap item. If modularization is unfunded or deprioritized, this dependency has no reason to enter the stack, regardless of how clean the abstraction is.
• Whether to standardize on Orchestra Platform conventions. Adopting this is a commitment to Orchestra's config-merge and extension-manifest patterns. That's an ecosystem bet, not a library pick — it should be weighed alongside "do we want our bootstrap layer to follow a convention the core framework doesn't know about?"
• Admin-toggleable capability packs. If product wants ops or customers to enable/disable modules without redeploying, a provider-driven loader is the enabling mechanism. This package sits underneath that capability, not on top of it.
• A deprioritization signal for the roadmap. Near-zero community footprint (no stars, no indexed dependents, low opportunity score) means this should never anchor a strategic initiative on its own merits. The most common correct decision it supports is "we are already on Orchestra, so use the sanctioned component" — otherwise, decline.
• Dependency-governance policy. It forces a real PM question: how much supply-chain and bus-factor risk are we willing to carry for a convenience abstraction over Illuminate\Support\ServiceProvider, which Laravel already provides for free?

When to Consider This Package

Adopt only when all of the following hold:

• You need dynamic or deferred provider registration — providers discovered at runtime, conditionally loaded based on config or tenant context, or lazily booted. Standard Laravel auto-discovery and bootstrap/providers.php do not cover this cleanly.
• You are building or maintaining an Orchestra Platform application or an extension that must target Orchestra's provider conventions, where ecosystem interoperability matters more than dependency independence.
• You prefer convention over invention — an existing ecosystem abstraction over a homegrown provider manifest and deferred-loader.
• The team accepts the negligible community footprint and can pin, vendor, read the source, absorb upgrade work, and fork if the maintainer goes quiet.

Look elsewhere when:

• You only need standard Laravel provider registration. Laravel's provider discovery, package auto-discovery, and DeferrableProvider already cover this; the dependency adds indirection, not capability.
• Your modular architecture is not provider-centric — e.g., Composer path repositories, nwidart/laravel-modules, or an event-driven plugin host.
• Maintenance risk is unacceptable. With effectively no downstream dependents, bus factor and long-term support become yours. For a long-lived commercial product, prefer a dependency with visible adoption or budget a fork as the plan of record.
• You need plugin governance — sandboxing, versioned contracts, capability permissions. This package handles registration, not isolation; that layer must be built or bought separately.
• Your Laravel major is outside the declared support range. The v7.0.0 line targets Laravel 9+; verify the current tag's composer.json before scoping anything, and never force a resolution with --ignore-platform-reqs.

Default stance: wrap or drop unless Orchestra Platform is already in the stack. If it is, pin it, document ownership, and pre-agree the fork trigger — typically "no compatible release within N weeks of a Laravel major."

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source plumbing component that helps Laravel applications load optional feature modules cleanly — nothing more. It is not a product feature, carries no direct commercial upside, and delivers value only if we fund the modular/extension-architecture roadmap item and only if we're already aligned with the Orchestra Platform conventions it belongs to. There is a real cost attached to adoption: with effectively no stars and no known dependents, the maintenance obligation becomes ours. Recommendation: do not make this a decision point on its own; note it as an available building block, revisit only if modularization is funded, and if adopted, treat it as a governance item with a named owner and a fork contingency.

To engineering: Evaluate orchestra/support-providers as a provider-registration utility, not a framework. It's worth a look if we genuinely need deferred, discoverable providers for a plugin or module system and are comfortable pinning — and potentially forking — a low-traffic dependency. Before adopting: confirm the current tag's Laravel/PHP require constraints, read src/ end to end (the package is small) to document the exact registration semantics we'd consume, and decide honestly whether native Laravel provider discovery plus a thin internal wrapper gives us 80% of the value with none of the bus-factor risk. If we proceed, wrap it behind an internal interface so it stays swappable and lock-in is confined to one or two files. Practical ramp-up is roughly half a day; the durable cost is the recurring review and keeping the "why do we have this" answer written down. Watch for the known failure modes: silent boot errors surfacing as null bindings far from the cause, deferred-provider semantic mismatches between Orchestra and Laravel, and a stale Laravel constraint that blocks a framework upgrade for the whole application.