Extras Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow: slim/extras is a resource/utility collection for the Slim micro-framework — not a Laravel package. Its value to us is as a reference implementation for HTTP middleware, PSR-7 request/response handling, and small auth/caching/logger helpers, not as a runtime dependency. Use it to answer "do we hand-roll this, or adopt an established library?" for thin HTTP concerns.
• Architecture boundary decisions: Informs whether a lightweight microservice (Slim-style, minimal footprint) or a full Laravel service is the right container for a new API. Useful when scoping an edge/gateway service where Laravel's bootstrap cost is hard to justify.
• Roadmap input on interoperability: Concrete examples of PSR-7/PSR-15 middleware composition, which is the same contract behind Laravel's HTTP kernel and symfony/psr-http-message-bridge. Helps us decide how much PSR abstraction to expose in our own packages.
• Prototyping and spike budgets: For a 1–2 day technical spike on request/response transformation, reading ~500 lines of Slim-Extras beats standing up a new Laravel module. Cheap way to de-risk a design before committing sprint capacity.
• Not a feature decision: Given 0 dependents, deprecated status, and a low opportunity score (~21), this package should not appear on a feature roadmap, a dependency review, or a security review as an asset to adopt.

When to Consider This Package

Adopt-adjacent (reading only) when:

• We are already running Slim 2/3 somewhere in the estate and need to document or migrate that code. Here it's a migration artifact, and the correct PM action is a decommission plan, not an adoption plan.
• We need a worked example of PSR-7 middleware ordering, HTTP caching headers, or a minimal auth handler to benchmark our own design against.
• A spike needs a proven pattern quickly and the team would otherwise over-engineer.

Look elsewhere when:

• The stack is Laravel. There is a framework mismatch. Use Laravel's native middleware, Http client, Gates/Policies, and symfony/psr-http-message-bridge + nyholm/psr7 if PSR-7 interop is genuinely required. Adding a Slim utility library to a Laravel composer.json creates two HTTP abstractions with no owner.
• The package is deprecated. No security patches, no PHP 8+ guarantees, no maintainer response. Flag this as a supply-chain risk in any dependency review; the correct disposition is "reference only, never in require."
• You need maintained equivalents. Prefer actively maintained, single-purpose packages (nyholm/psr7, laminas/laminas-diactoros, middlewares/*, monolog/monolog) over a bundled "extras" grab-bag.
• You need vendor support or SLAs. Not applicable at any tier.

How to Pitch It (Stakeholders)

To executives (one paragraph): slim/extras is a deprecated utility collection for a PHP micro-framework we do not use. I am not recommending we adopt it. I'm recommending we treat it as free prior art: a small, readable reference for HTTP middleware and request/response handling that can shorten design spikes for our API work. Cost of the recommendation is zero engineering hours of dependency maintenance and zero added supply-chain surface; the benefit is a faster, better-informed design decision on one or two upcoming API initiatives. If the team instead wants a runtime dependency, the answer is no — the package is unmaintained and framework-mismatched.

To engineering (the actual ask):

• Do not add slim/extras to any composer.json. Deprecated, 478 stars, 0 dependents, no security patching. Treat as read-only reference material.
• If we need PSR-7/PSR-15 patterns, point engineers at the source for ideas and at maintained packages (nyholm/psr7, symfony/psr-http-message-bridge) for code.
• If any internal service still depends on Slim, surface it now — that's a migration line item, and this package's deprecation is the trigger to schedule it.

Bottom line for the decision log: No adoption. Reference value only. Reassess if a Slim service is discovered in the estate, in which case the outcome is a decommission plan, not an integration plan.