Facade Bundle Laravel Package

Product Decisions This Supports

• Developer experience (DX) investment for Symfony teams with Laravel DNA. The package lets engineers call services through a static, Laravel-style facade (Cache::get(...), SomeService::doThing()) instead of wiring constructor dependencies. v0.2.0 adding Symfony 5 compatibility makes this more credible for teams currently on Symfony 5, but it does not address Symfony 6/7. This still informs a "reduce onboarding friction" roadmap item when a meaningful share of the team is Laravel-trained and is being moved onto Symfony.
• Build vs. buy vs. vendor for internal ergonomics tooling. With 17 stars, zero dependents, and only a narrow Symfony 5 compatibility release in v0.2.0, this is still not a "buy" decision in any commercial sense. It is a candidate for vendoring/forking into an internal utility package. The decision it supports is whether to spend ~1–2 engineer-days reproducing the facade-resolution layer internally rather than take a thinly maintained dependency. v0.2.0 gives a slightly newer baseline to fork from, but does not change the ownership calculus.
• Framework migration and consolidation strategy. If the org runs mixed Laravel/Symfony estates, this package is evidence for or against standardizing on one framework's idioms. v0.2.0 improves its relevance only for Symfony 5-era migration paths; it is not evidence that "Laravel-flavored Symfony" is a safe permanent architecture. It supports a decision about whether this is an acceptable time-boxed intermediate state or debt you refuse to take on.
• Greenfield internal tooling vs. customer-facing platforms. The facade pattern is attractive for small internal admin tools, scripts, and prototypes where ceremony outweighs testability concerns; it is a poor fit for long-lived, heavily unit-tested, or public-facing services. This package helps frame that segmentation, with v0.2.0 making Symfony 5 internal tools the clearest viable niche.
• Architecture guardrails policy. Adopting it implies a stance on service locator usage. That decision (allow facades in app/UI layer, forbid in domain layer) is a coding-standards/roadmap artifact the PM should own alongside engineering.
• Risk register input. v0.2.0 is a meaningful signal — the package is not completely abandoned — but a single Symfony 5 compatibility release after a long dormant period is not a maintenance commitment. Last release content, star count, dependents count, and missing Symfony 6/7 support remain concrete data points for dependency-risk scoring and for negotiating a maintenance owner if adopted.

When to Consider This Package

Consider it when:

• The team is predominantly Laravel-experienced, is ramping on Symfony, and you want to shorten time-to-first-PR without rewriting muscle memory.
• The target runtime is Symfony 5 or can be constrained to it; v0.2.0 explicitly adds Symfony 5 compatibility, so this is the first release where that path is plausible without immediate porting.
• The target is internal tooling, prototypes, or short-horizon apps where a service locator's downsides (hidden dependencies, harder isolated testing) are acceptable.
• You are prepared to fork and own it — pin v0.2.0 or a later commit, audit the code (it is small enough to read in an afternoon), add PHP 8.1+/Symfony 6/7 compatibility if needed, and carry the maintenance cost internally.
• You need a transitional shim, not a permanent architecture: a clearly time-boxed bridge during a Laravel → Symfony migration, ideally on Symfony 5.
• MIT licensing is sufficient for your legal posture and you can accept a "no upstream support" SLA.

Look elsewhere (or build the 100–200 lines yourself) when:

• You need active maintenance, security patching, or vendor support — v0.2.0 is a narrow compatibility release, not evidence of a sustained release cadence; zero dependents still means effectively no upstream community.
• You're on Symfony 6/7 and PHP 8.2+ — v0.2.0 stops at Symfony 5, so the package still predates current bundle/DI conventions and will need real porting work; verify before committing.
• Your architecture standard is constructor injection and explicit dependencies (the idiomatic Symfony position). Facades fight autowiring, complicate static analysis, and make unit tests require container bootstrapping.
• You're building a long-lived, customer-facing, high-compliance platform where hidden global state is a liability.
• You need observability, request-scoped correctness, or async/queue worker safety — service locators resolved at static call time are a common source of stale-container and long-running-worker bugs.
• Your dependency policy forbids thinly maintained or abandoned packages; treat this as a blocker and route to the fork-and-own path instead.

How to Pitch It (Stakeholders)

One-liner: A small MIT-licensed Symfony bundle that brings Laravel-style facades to Symfony services. v0.2.0 adds Symfony 5 compatibility, which improves its fit for Symfony 5 internal tools, but it remains a thin dependency we should vendor rather than rely on for modern Symfony.

For executives: The opportunity is developer productivity, not capability — it makes Symfony feel familiar to Laravel engineers and can compress ramp-up time on internal tools. The cost is near zero (MIT, tiny surface area), and v0.2.0 shows the project is not completely dead. But the vendor commitment is still weak: 17 GitHub stars, no dependents, and only a narrow Symfony 5 compatibility release after a long gap. Recommendation: do not add it as a production dependency for a modern Symfony stack. If we have a Symfony 5 internal-tooling use case, treat it as reference material or an internal fork with a named owner and an explicit exit path back to standard Symfony DI. Upside is real but bounded; downside is a small, contained maintenance line item.

For engineering: The package is small enough to audit and reimplement. v0.2.0 adds Symfony 5 support, so pin that release if we deliberately choose the Symfony 5 path; do not assume Symfony 6/7 or PHP 8.2+ support. Adopt the pattern deliberately — permitted in the presentation/application layer, prohibited in the domain layer — or skip it and stay idiomatic with constructor injection. If we adopt, we fork it, pin the commit, add the Symfony 6/7 and PHP 8.2+ support we actually need, write tests, and record it in the dependency-risk register. Do not let it become ambient architecture by default.