- Does itsgoingd/slim-facades work with Slim 4?
- No, it is designed around the Slim 3 lifecycle, where a PSR-11 container is attached to the app via getContainer() and facades can resolve keys from it. Slim 4 removed that model in favour of app-level container wiring and immutable request/response objects passed through middleware, so the facade Request and Response accessors would be semantically wrong there. Check the composer.json version constraint before adopting it; if you are on Slim 4, use constructor injection instead.
- How do I install and configure slim-facades in a Slim 3 app?
- Run composer require itsgoingd/slim-facades, then register the container once during bootstrap with Facade::setFacadeContainer($app->getContainer()). If you need per-request facade access, add the package's companion middleware to your middleware stack so the current request instance is bound on each cycle. There is no schema, config tree or service provider contract to set up, so the whole integration is a couple of lines.
- Which services can I access through the facades?
- The facades are thin proxies that resolve container keys, so anything you have registered can be reached statically, including the commonly used router, view, logger, settings, request and response entries. The package ships facades for the typical Slim services plus a generic facade base class you can extend for your own container keys. If a key is missing from the container, the static call fails at runtime rather than at compile time, so keep your registrations explicit.
- Is slim-facades safe to use under RoadRunner or Swoole?
- A process-global facade container is fine under PHP-FPM, where each request gets a fresh process scope. Under long-lived workers such as RoadRunner or Swoole, a stale container or stale request can leak between requests unless the middleware reliably rebinds and resets state on every cycle. If you run a worker runtime, prove the per-request rebinding with a test before shipping, or restrict facade usage to a stateless edge layer.
- How do I unit test code that calls slim-facades facades?
- Static calls bypass constructor injection, so any class that touches a facade needs a bootstrapped container before it can be exercised. You can point Facade::setFacadeContainer() at an alternative or mock container in your test setup, which gives you a swap story, but there is no way to test such code as a plain isolated unit. The practical answer is to keep facades in routes and controllers, where container-backed integration tests are appropriate, and out of domain services.
- Does slim-facades conflict with PHP-DI or League\Container?
- The package does not replace your container, it reads from whatever PSR-11 instance you hand it via setFacadeContainer(). That means PHP-DI, League\Container or Pimple can all sit underneath, as long as the keys the facades expect are actually registered. The risk is duplication of conventions rather than a hard technical conflict, so decide up front whether facades are the canonical access path at the HTTP edge or just a convenience layer.
- Is slim-facades still maintained and is it production ready?
- It is a small, single-maintainer package with a modest star count and sparse activity, so treat it as a convenience dependency rather than a critical one. The blast radius is contained because removing it means refactoring static call sites back to injected dependencies in your edge layer. If long-term availability matters, plan to vendor the source or fork it rather than depending on regular releases.
- Can I use slim-facades facades in domain services and repositories?
- You can, but you should not. Calling Request:: or Log:: from below the HTTP edge inverts the dependency direction and makes unit tests require a bootstrapped container, which is a classic testability regression. A workable rule is to allow facades in routes, controllers and middleware only, and enforce it with a PHPStan or Psalm rule or a simple grep check in CI. That keeps the ergonomic win while preserving explicit boundaries.
- What alternatives exist to slim-facades for cleaner dependency access in Slim?
- The main alternative is plain constructor injection with a PSR-11 container such as PHP-DI or League\Container, which keeps dependencies visible to IDEs and static analysis. If your team already thinks in Laravel idioms and velocity matters more than architectural purity, facades are a reasonable shortcut. If you need Laravel-style facades plus the wider ecosystem, moving to Laravel itself is usually a better long-term answer than porting the idiom onto Slim.
- How much effort is it to remove slim-facades later?
- Removal is a bounded refactor of the edge layer: replace static calls like Router::get() and View::render() with injected dependencies in your controllers and middleware. Because the package adds no routes, middleware pipeline behaviour or database schema of its own, nothing else in the app depends on it. Introducing it behind a documented boundary now makes that future migration cheap.