Flash Laravel Package

Product Decisions This Supports

• Framework fit is still the first decision, and it's still a negative one for Laravel. Despite the framing, slim/flash is a Slim 3 service provider, not a Laravel package. If the roadmap is Laravel, this is a non-option — session()->flash() and redirect()->with() are in the framework, maintained, and already paid for. The decision it actually supports is "confirm stack before shortlisting dependencies."
• Build vs. buy for a commodity capability. Flash messaging (write a transient message to session, read-and-clear it after a redirect) is ~20–150 lines of code. This package is the "buy" side of that trade, and it remains a cheap buy: MIT, single purpose, small API surface ($container['flash']). For an existing Slim 3 service, that's a defensible afternoon saved.
• Maintenance signal improved, but it is a signal, not a cadence. The 0.4.0 release is the first in roughly eight years and lands three small additive features — getFirstMessage(), clearMessage() / clearMessages(), and a configurable storage key. This is evidence someone is still holding the door open, not evidence of a roadmap, security process, or support commitment. Planning should still treat flash messaging as an internal capability we own, with the library as an optional starting point.
• The new features map to real product flows, which is the strongest argument for the release. getFirstMessage() simplifies the common "show exactly one banner after redirect" pattern (single success notice, single blocking error) without index juggling in views. clearMessages() makes test setup and long-lived worker processes sane — you can reset notice state deterministically instead of reconstructing the container. A custom storage key lets two apps or two notice channels share a session without colliding, which is the difference between "usable in a multi-tenant admin" and "globally invasive."
• No breaking changes, so the upgrade decision is cheap. Nothing in this release forces a migration, changes defaults, or invalidates existing $container['flash'] usage — the storage key is configurable, implying the current default is preserved. Upgrade cost is a version bump plus a re-read of a very small diff.
• Use cases it can serve: legacy Slim 3 admin panels, internal tools, and simple form flows (post/redirect/get) that already use Slim's Pimple container and need success/error notices without bespoke session plumbing — now also small multi-flow apps that need per-channel message isolation or explicit state resets.
• Risk decision it forces, explicitly: adopting a lightly-maintained package means we own the fork. That belongs in the ADR as a named cost, not as a default that happens because someone ran composer require. The release lowers the "is this dead?" probability slightly; it does not remove the ownership cost.
• Opportunity scoring input: still low. The capability is table stakes in every modern PHP framework, so there is no differentiation upside — the value is in the UX flows it enables (clear post-submit confirmation, recoverable errors), not in the library choice.

When to Consider This Package

Consider it only if:

• You are on Slim Framework 3 and using its Pimple-based container / service-provider pattern. The package targets that model; Slim 4's container and middleware conventions are not what this was written against, and 0.4.0 does not change that.
• You have a small number of post/redirect/get flows and want the smallest possible dependency rather than hand-rolled $_SESSION handling.
• You need one-notice-at-a-time rendering (getFirstMessage()), deterministic resets in tests or long-running workers (clearMessages()), or a non-default session key to avoid collisions with other notice channels — these are the specific gaps 0.4.0 closes and the concrete reasons to take the new version over the old one.
• Your team accepts forking and owning it. MIT license, tiny surface, readable code — vendoring into the monorepo, pinning, and maintaining it is realistic.
• You specifically want the service-provider shape ($container['flash']) rather than a helper class.

Look elsewhere (or write it yourself) if:

• You are on Laravel — use the built-in session flash and redirect helpers. No dependency needed, and nothing in this release changes that.
• You are on Slim 4 — this release predates those conventions; write the few lines yourself against the current session middleware instead.
• You require active maintenance, a release cadence, security review, or CVE response. One release after eight years is a heartbeat, not a support contract: there is no published cadence, no dependents to surface breakage, and no security process visible.
• You need typed messages, message priorities, or cross-request persistence beyond a session key — trivial to add in-house, and still outside what this package promises.
• The codebase is client-facing or audited and cannot carry an unsupported transitive dependency.

How to Pitch It (Stakeholders)

For executives: This is a tiny, free utility for showing "your changes were saved" style notices after a page redirect. Three things matter. First, it's built for Slim, not Laravel — if our stack is Laravel we already have this behavior in the framework and should not add it. Second, there is a new release (0.4.0) with three small additions — retrieve the first pending notice, clear all notices at once, and configure which session key is used — none of which are breaking. That's a mildly positive maintenance signal after roughly eight years of silence, but it is not a support commitment or a roadmap. Third, essentially nothing depends on it, so it is a snippet, not a foundation. Recommendation: don't adopt it as a standing dependency. If a Slim service needs flash messages, budget a day to vendor or reimplement it so we own it outright — and if we do take it, pin the new version for the three conveniences it adds.

For engineering: It's a thin session-backed message store wired into Slim's container — set, get-and-clear, nothing more. MIT, no transitive weight, easy to read in one sitting. 0.4.0 adds getFirstMessage(), clearMessage() / clearMessages(), and a configurable storage key; these are additive and low-blast-radius, and the configurable key implies the default session key is unchanged, so existing call sites keep working. The cost isn't integration, it's ownership: still no Slim 4 alignment, and one release after eight years is not a cadence. If we take it, fork it into the repo, pin 0.4.0 or later, and add it to the dependency-review list — the bulk-clear and first-message helpers are worth having if we're maintaining the fork anyway, since they're the parts we'd otherwise write ourselves.

PM framing: Score flash messaging as a commodity capability with low strategic opportunity. The 0.4.0 features are quality-of-life improvements for implementers, not product capabilities — they make "show exactly one confirmation," "reset notices between tests," and "keep our notice channel separate from someone else's" easier, which means slightly less engineering time per flow and slightly fewer notice-rendering bugs. Spend product attention on the flows it unlocks — obvious post-submit confirmation, recoverable validation errors, clean multi-channel admin screens — and let engineering pick the cheapest safe implementation. Do not let a feature plan depend on this package's release schedule; one release in eight years is not a schedule.