Slim Facades Laravel Package

Product Decisions This Supports

• Developer velocity vs. architectural purity trade-off. The package trades explicit dependency injection for Laravel-style static access (Container::get(...), Request::..., Response::..., View::..., Log::...). As a PM, this is a decision about shipping speed on small surface areas versus long-term testability — not a platform decision.
• Build vs. buy (and "build vs. borrow"). The package is a thin wrapper over Slim's container, likely a few hundred lines. The real choice is: adopt a 74-star, single-maintainer dependency, or spend half a day replicating the 5–6 facades your team actually uses. For most teams, the honest answer is the latter.
• Legacy Slim 3 sustainment vs. rewrite. This is most useful as a stay-alive tool for an existing Slim 3 codebase: it reduces boilerplate in controllers and route callbacks, making incremental feature work cheaper while a rewrite is scoped. It is not a foundation for new work.
• Onboarding and team ergonomics. If your team has Laravel muscle memory, facades lower the cognitive switch cost when maintaining a Slim service. That directly affects ramp-up time and the cost of rotating engineers onto the codebase.
• Framework migration sequencing. Adopting facades increases coupling to Slim 3's container internals, which is a real input into "migrate to Slim 4 now vs. later" or "port to Laravel" decisions. If a migration is already funded, skip this package — it adds work to unwind.
• Test architecture decisions. Static facades require container bootstrapping in tests. If your team has standardized on pure constructor injection and PHPStan/Psalm at high levels, this pulls in the opposite direction and should be explicitly ruled out rather than discovered later.

When to Consider This Package

Adopt only when all of the following hold:

• You are on Slim 3 (the facades are built around Slim 3's container/app model — do not assume Slim 4 compatibility; verify against your version before committing).
• The codebase is legacy or internal-facing, with a bounded remaining lifespan or a funded exit path.
• The team is small and Laravel-familiar, and the bottleneck is boilerplate, not architecture.
• You accept single-maintainer risk (itsgoingd) and the absence of an active release cadence.

Look elsewhere when:

• You are on Slim 4 — use native PSR-11 container injection, or a modern PSR-7/PSR-15 stack; facades are the wrong idiom there.
• You are starting greenfield — constructor injection and PSR standards cost little upfront and avoid a future refactor.
• You are in a Laravel application — use Laravel's own facades; this package adds nothing.
• You enforce strict static analysis or high test-coverage gates — static access fights both.
• The product is long-lived and business-critical — depending on an unmaintained wrapper for an EOL framework is a liability, and Slim 3's own end-of-life is the bigger signal.

How to Pitch It (Stakeholders)

To executives: This is a low-cost developer-ergonomics helper, not a platform bet. It lets engineers write Slim code in a style they already know, which shaves time off maintenance work on an existing service. Risk is contained because the library is thin — if it's abandoned or we move off Slim 3, ripping it out is a small, well-understood task rather than a migration. Recommendation: approve only for legacy/internal services, with a documented exit path, and do not let it set the pattern for new products.

To engineering: It gives you Laravel-style facades over Slim 3's container — Request, Response, View, Log, Router, Container — so you stop threading the container and request object through every layer. The cost: static state makes unit testing harder, static analysis needs docblock help, and the package is a single-maintainer project tied to an EOL framework. Treat it as scaffolding for code we intend to replace, not as an architectural standard. If you're on Slim 4 or starting fresh, we should decline it and use proper DI.