- What is indragunawan/facade-bundle and what problem does it solve?
- It is a lightweight package for organizing related facades into reusable facade bundles, so you can group static access to container-bound services instead of scattering one-off facade classes and imports across a codebase. It preserves Laravel's familiar static facade syntax while giving your services a consistent, discoverable API. It also lets you register bundles cleanly through a service provider rather than wiring each facade individually. The value is mostly ergonomic: fewer boilerplate imports and a tidier static surface.
- How do I install indragunawan/facade-bundle with Composer?
- Install it with composer require indragunawan/facade-bundle, then register the bundle through your application's service provider mechanism. Per-facade classes extend the package's base facade and expose an accessor that returns the container service ID they proxy to. Before you commit, run composer why-not indragunawan/facade-bundle against the framework version you actually target so you see the real constraint rather than assuming compatibility from the changelog. A throwaway container boot on your target version is a cheap final check.
- Which Laravel and PHP versions does this facade bundle support?
- The package description does not state an explicit Laravel version range, so treat the supported envelope as unconfirmed until you check the tag's composer.json. The technical evaluation notes that the only recent release, v0.2.0, is a Symfony 5 compatibility bump after a gap of more than four years, which points to a confirmed envelope of Symfony 4.4/5.x and roughly PHP 7.4 through 8.0. PHP 8.2 and 8.3 support is explicitly unverified, and Symfony 6 and 7 are not supported. Inspect the platform constraint in composer.json rather than inferring PHP support from a framework constraint bump.
- How do I create and register a facade bundle in my application?
- Define one facade class per service, each extending the package's base facade with an accessor returning the service ID, then group those classes into a bundle and register the bundle once instead of registering each facade separately. Registration happens through your framework's normal mechanism, which in the description is a Laravel service provider and in the evaluation is a config/bundles.php entry. Keep the service ID mapping in a single place so a rename is a one-line change you can grep for. Add a smoke test that resolves every facade in the bundle so any stale ID fails in CI rather than in production.
- Does this package work with Symfony or is it Laravel-only?
- The package name, description, and blurb frame it as a Laravel package for bundling facades, but the technical evaluation describes it as a Symfony bundle that ports Laravel's Facade pattern onto Symfony services. Confirm which side your composer require actually pulls by reading the package type and dependencies before installing. The distinction matters because the facade pattern is architecturally backwards on Symfony, where explicit constructor injection is the convention and facades reintroduce a service locator that hides dependencies from the call graph and from the container's compile-time validation.
- How do facade bundles resolve services from the container?
- Each facade is a static proxy that looks up its underlying service from the container by a string ID at call time and forwards the call to that instance. That keeps the familiar Foo::bar() syntax while the actual object stays container-managed and swappable. The trade-off is that resolution happens lazily at runtime, so the container cannot validate the reference when it compiles. Static analysis tools such as PHPStan and Psalm also lose sight of the dependency, since it never appears in a constructor signature.
- Is it safe to use facades in long-running workers like Laravel Octane, FrankenPHP, RoadRunner or Swoole?
- Treat this as a correctness risk, not just a style preference. Static facade state can persist across requests in worker-mode runtimes such as FrankenPHP worker mode, RoadRunner, and Swoole, and the v0.2.0 release does not address this. If your target runtime uses long-running workers, audit any mutable state held on the facade or the resolved service, or restrict the bundle to traditional request-per-process FPM deployments. The package's maintainer has not published guidance on this.
- What happens if I rename or remove a container service that a facade points to?
- The facade's string-keyed accessor will no longer resolve, and the failure surfaces at runtime in the call path rather than at container compile time. That means a refactor that looks complete can still break the first code path that touches the facade. Reduce the blast radius by keeping service IDs in constants and covering each facade in the bundle with a resolution test that runs in CI. Because the dependency is invisible to static analysis, a grep for the raw string is often your only early warning.
- What are the alternatives to adding this package as a dependency?
- Laravel already ships a Facade base class, so grouping related facades behind a few of your own classes is often a small amount of code with no external dependency. The evaluation makes the same point for Symfony, where a roughly 60-line in-house facade costs less than owning the dependency. The alternative that best preserves injection discipline is to skip facades entirely and use explicit constructor injection, accepting the extra wiring in exchange for dependencies that appear in the call graph and in static analysis. Choose this package only if the ergonomics win is concrete for your team.
- Is indragunawan/facade-bundle actively maintained and what is the adoption risk?
- Governance is thin: a single maintainer, a small star count, and effectively no dependent base to surface regressions. The v0.2.0 release was the first in over four years, and its entire changelog is a one-line Symfony 5 compatibility note, which is equally consistent with a real refactor and with a composer.json constraint bump. One release is not a maintenance cadence, and Symfony 5 itself is on an end-of-life track. Pin the exact version, read the diff rather than the changelog, and decide up front who owns the fork and what your patch SLA is for the next PHP or framework major bump.