Support Laravel Package

Product Decisions This Supports

• Build vs. buy for internal scaffolding. The package's value is avoided boilerplate, not shipped capability. If the team maintains more than one Laravel package or addon, this answers a governance question: write and own our own support layer, or inherit one that already encodes shared conventions. Adoption cost is near zero; building an equivalent costs engineering days better spent on product.
• Standardization across a package portfolio. Adopting it is an agreement that helper classes, string/array utilities, provider bootstrapping, and package-level conventions live in one dependency instead of drifting per repo. Expected payoff: lower onboarding cost, fewer "how did we do this in the other package?" review cycles, and one convention enforced in review rather than many.
• Roadmap sequencing against Laravel 9+. v7.0.0's only documented change is raising the framework floor to Laravel 9+. That is a platform-version decision disguised as a dependency bump — it lands with the Laravel 9+ migration or it does not land at all. Same initiative, not a separate ticket.
• Effort estimation for addon and maintenance work. Because the release is environmental rather than functional, any estimate framed as "upgrade the package" misleads. The work is dominated by the framework migration; the package bump is a constraint change plus a regression pass.
• Direct vs. transitive classification as a PM checkpoint. Before allocating capacity, answer with composer why orchestra/support whether we are choosing this dependency or inheriting it — most often via orchestra/testbench. If it is inherited and nothing calls its API, the correct decision may be to drop it from production requirements rather than sequence an upgrade for it.
• Dependency-risk tolerance and exit criteria. Public adoption signals are effectively nil: no stars recorded, no dependents, low score. For a foundational utility that means betting on a single niche ecosystem rather than a widely exercised library. Treat it as a convenience layer for internal tooling, keep it off customer-facing critical paths, and price the "replace it" option before you need it.
• Reversibility as a low-stakes approval. Small, Composer-installable, swappable. That justifies approving a time-boxed spike — an afternoon in a throwaway package — rather than a multi-sprint commitment. Cheap to decide, cheap to undo.

When to Consider This Package

Adopt it when:

• You are building or maintaining Orchestra Platform packages or addons. That is the intended audience; outside it, most of the value evaporates.
• You maintain more than one Laravel package and want shared conventions — one home for provider bootstrapping, helpers, and traits instead of copy-paste across repositories.
• You are already on Laravel 9+ (PHP 8.0/8.1+), or that migration is funded and scheduled. v7 is gated on the framework version; on 9+ it is close to a drop-in.
• You want lightweight, Composer-only integration — no database footprint, minimal operational surface, no new infrastructure in the deploy path.
• It arrives transitively via Orchestra tooling. Then it is a dependency decision by inheritance: confirm the source and confine it to require-dev rather than promoting it into the production autoload path.

Look elsewhere, or deliberately pass, when:

• You are on Laravel 8 or older and the migration is not funded. The real estimate is the framework upgrade; the package bump is the small part. Pin the prior major and carry a dated remediation ticket.
• You are not in the Orchestra ecosystem. Generic Str/Arr/collection work is better served by Illuminate\Support, which is battle-tested, universally understood, and already a dependency.
• The dependency is inherited only through testbench and no application code calls its API. Removing a foundational dependency nobody uses is a net risk reduction and takes minutes.
• The helper would sit on a customer-critical path. Near-zero public adoption, no vendor SLA, and one effective maintainer make this a poor foundation for revenue-facing flows.
• You need documentation before adoption. There is no meaningful docs site and the major-version changelog is one line. If the team cannot budget reading vendor/orchestra/support/src first, this is the wrong dependency to bet on.

How to Pitch It (Stakeholders)

To executives: The package is a shared utility layer for the Orchestra Platform — small, free, and already part of how our Laravel package tooling is assembled. It does not add a database, a service, or an operational cost. The decision in front of us is not "adopt a new platform"; it is "standardize our internal package scaffolding on a dependency we are largely already inheriting." The honest risk is bus factor: no public adoption signals, no vendor SLA, effectively one maintainer. That risk is affordable for internal tooling and not affordable for customer-facing paths. Recommendation: approve a time-boxed spike, keep it out of production autoload unless deliberately promoted, and name an internal owner who watches upstream releases.

To engineering: The high-value, low-risk entry point is extending the package's base service provider for our own packages. That is where the payoff lives — one registration convention instead of drift between repositories, fewer "how did we register routes and facades in the other package?" reviews. Pair it with a thin internal wrapper (Acme\Support\Notices around their Messages, an internal provider base extending theirs) so call sites never touch the vendor class and a future major version surfaces in one file. Test through orchestra/testbench, not mocks. Watch two specific hazards: namespace collision with Illuminate\Support (alias imports, and never let one file use both vocabularies), and any singleton in-memory registry — that is per-process state and the single most likely production incident in queue workers or Octane, so scope it per request or reset on terminate().

The ask and the guardrails: Budget an afternoon to prove it in a scratch package before it touches a product repo. Keep it in require-dev where it is only arriving transitively. Sequence the next major as two PRs — framework upgrade first, package bump second, never combined, so a regression is unambiguously attributable. And put "Laravel support ceiling for foundational dependencies" on the platform roadmap as a recurring line item: a utility package that stalls on the next Laravel major freezes every dependent package simultaneously — highest impact, lowest visibility.