Support Facades Laravel Package

Technical Evaluation

What it is, in product terms. orchestra/support-facades is not a capability — it is a convention packaged as a dependency. It ships reusable facade base classes, container-backed accessors, and a registration/aliasing helper so that Orchestra-family packages can expose services through static syntax. The TPM framing follows directly: the question is never "what does it do," it is "is a few dozen lines of boilerplate avoidance worth a permanent row in our upgrade matrix, a supply-chain review per release, and a named owner in the dependency inventory?"

Architecture fit. Narrow and conditional:

• Good fit inside an Orchestra Platform estate (alongside Testbench/Kernel/Asset), where these bases remove repeated plumbing and keep a consistent static API across internal components. There it is dependency alignment, not a choice.
• Poor fit for a conventional Laravel application. Current Laravel practice favours constructor injection and container resolution; a facade-first layer institutionalises static coupling and works against testability and dependency explicitness. The package solves a problem most product teams do not have.
• Wrong fit below Laravel 9. v7.0.0 raises the framework floor; it is a hard constraint, not a compatibility shim.

Integration feasibility. Install and wiring are trivial — Composer require, alias, done. The real feasibility risk is organisational: each added package buys a recurring upgrade obligation, and here the thing being bought is small enough that "write it ourselves" is a genuinely competitive option. That belongs in the build-vs-buy record, not assumed away.

Technical risk — elevated for a package this small, for signal reasons more than code reasons:

• Adoption signal is weak. Zero dependents and negligible traction indicate maintainer-internal ecosystem tooling. There is no user base to surface bugs, no third-party guidance, and no realistic prospect of a maintained community fork.
• Single point of failure. Continuity depends on one maintainer and one organisation's continued investment in Orchestra. That is a governance risk to register, not an engineering backlog item.
• Blast radius exceeds the release note. A facade layer is a public surface; every static call site is a coupling point. "Laravel 9+" may be the only documented change, but a v7 major can legitimately alter base-class signatures, alias resolution, or accessor behaviour — and those break at runtime, not at install.
• A framework floor is not a support guarantee. Laravel 9 is past security support; treating the package floor as our standard would create immediate debt.

Key questions to close before a decision:

• Are we already on the Orchestra Platform? If yes, this is version lockstep with the other orchestra/* packages, not adoption.
• If not, what do we get that a ~50-line internal base class does not? Name concrete call sites.
• What is the actual supported matrix — Laravel 9 only, or 9 through current — and what does CI cover?
• Did v7.0.0 carry breaking changes to facade bases, aliasing, or resolution beyond the constraint bump? Is there a v6→v7 migration guide?
• Is v6 still patched for Laravel 8 estates, and until when?
• Who maintains it, what is the release cadence across prior Laravel majors, and what is the security-disclosure path?
• Does licence and supply-chain posture clear our dependency policy?

Integration Approach

Stack fit. Adopt only where the stack already implies it: Laravel 9+ (realistically 10/11/12), PHP 8.1+, Composer 2, in an Orchestra package or platform context. Plain Laravel applications should default to "do not adopt" and write a thin internal adapter if facade-style access is genuinely wanted. Laravel 8 estates are out of scope for v7 entirely.

Build vs. buy — the decision that matters most. "Buy" carries no licence fee but a recurring cost: one upgrade ticket per Laravel major, one security review per release, one owner in the inventory. "Build" is a one-off small effort with full control. For this scope the honest recommendation is build — unless we are already inside the Orchestra ecosystem, where cross-package consistency outweighs the overhead. "It's free on Packagist" is not a substitute for this analysis.

Migration path (existing adopters). Treat v7.0.0 as a planned major, not a patch:

1. Inventory every package and application referencing it; pin Laravel 8 estates to the prior major with a named owner and a date.
2. Diff facade base classes and aliasing config across majors — do not assume the framework constraint was the only change.
3. Bump the constraint on a branch; resolve illuminate/* and Symfony constraints against the lockfile.
4. Re-publish or diff any published configuration.
5. Run the full suite plus targeted tests over every static call site — that is the actual regression surface.

Compatibility. Verify three layers before rollout: Laravel version, PHP version, and transitive constraints against packages that extend Laravel internals (admin panels, auth extensions, queue/cache drivers, test utilities). Because facade bases are designed to be subclassed downstream, check whether any of our own code extends them — subclassed bases are the likeliest silent break.

Sequencing.

1. Confirm ecosystem position: already-Orchestra vs. net-new dependency. This gates everything.
2. Run and record the build-vs-buy decision with rationale.
3. Confirm support matrix, changelog, migration guide, maintainer status, licence.
4. Pin legacy estates to the prior major.
5. Upgrade a non-production Laravel 9+ target first; diff config and base classes.
6. Full automated suite, then targeted regression over facade call sites.
7. Canary one production application with explicit rollback criteria.
8. Roll out by cohort, standardising on a currently supported Laravel version — never on the package floor.
9. Schedule the follow-on step to move off Laravel 9 if that is the minimum in play.

Operational Impact

Maintenance. Low code churn, non-zero process overhead. The recurring obligation is a per-Laravel-major upgrade plus a dependency review, and it exists whether or not the package changes. Assign a named owner, add it to the dependency inventory with a support-matrix note, and put Laravel end-of-life dates on a calendar review. Standardising on the package minimum (Laravel 9) is an explicit debt-creation decision and should be rejected in the plan.

Support. Support quality cannot be inferred from a release note, and with zero dependents there is no community safety net. Plan for self-support: our engineers debug issues, and an internal fork or vendored copy is a realistic and cheap contingency given the surface area. Confirm maintainer responsiveness and the security-disclosure route before putting it on a critical path.

Scaling. No performance or throughput concern is implied — resolution is container lookup. The scaling risk is organisational: more applications, more Laravel versions, and mixed package majors multiply upgrade coordination cost. Mitigate by narrowing to one supported Laravel band and one package major across the estate, and by keeping facade usage behind internal adapters so call-site count stays bounded.

Failure modes to plan for.

• Composer resolution conflicts against illuminate/* and Symfony constraints.
• Silent behavioural change in alias resolution or accessor methods after a major bump — surfacing at runtime, not install.
• Our own subclassed facade bases breaking on signature changes.
• Configuration drift after re-publishing.
• Maintainer investment lapsing, leaving the package behind a Laravel major and forcing a fork or unplanned refactor.
• The dominant failure mode: assuming a major is a drop-in because the only documented change is the framework constraint. Verify, don't assume.

Ramp-up. Engineering ramp-up is a few hours, not a training programme: a facade is familiar Laravel idiom, and the package only standardises the base class. The real on-ramp is process, not knowledge — engineers need the written convention for when a facade is appropriate versus constructor injection, the aliasing/registration pattern, and the test strategy for static call sites. Budget the effort on the review side: dependency policy sign-off, licence and supply-chain check, and a documented build-vs-buy decision. Expect no external documentation, tutorials, or community answers to lean on; internal notes are the support corpus. For a pilot, one engineer for a day covers integration plus a call-site inventory; broad standardisation should wait on that pilot's findings and on confirming the package tracks a Laravel version we actually support.