Rate Limit Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use-native — still settled as "use native," but the decision record needs a correction. The package shipped a v4.0.0 tag whose entire changelog is "Compatibility with PHP 8." That does not change the recommendation, but it does invalidate two claims in the prior assessment ("no release since Dec 2020," "no releases in 4+ years"). The decision to log-and-close stands; the supporting evidence must be restated accurately, or the next person to check the repo will discount the whole memo.
• Roadmap scoping for abuse prevention — unchanged. Per-route throttling for login endpoints, API quotas, export/search endpoints, and webhook receivers remains a real roadmap item. The build target is still the framework's native RateLimiter (Symfony 5.2+) or throttle middleware (Laravel), not this bundle. Nothing in v4.0.0 adds capability the platform does not already own.
• Legacy triage / risk register — priority unchanged, framing adjusted. If a Symfony 4.x service depends on this, it remains a tech-debt entry with a named owner. The new tag is a narrow plus (the dependency can now be installed on a PHP 8 runtime and can survive a runtime upgrade without a fork), but it provides no security-response signal and no forward-compatibility claim beyond the PHP 8.0 language level.
• Platform consistency — unchanged. One throttling story across services, shared config semantics, one thing to monitor. A single unannounced PHP 8 compatibility tag does not constitute a support story.
• Data-quality caveat to carry forward: this cycle's supporting data payload was empty, so stars/dependents/release cadence could not be re-verified. The adoption conclusion is carried forward on the strength of the prior read plus the absence of any contradicting signal, and should be re-checked before the memo is cited in a security or procurement review.

When to Consider This Package

The bar is now marginally clearer, because v4.0.0 tells us exactly how much is on offer: PHP 8 language-level compatibility and nothing else. Consider it only in these narrow cases:

• You maintain a Symfony ≤4.4 application that already depends on it, the service is being re-platformed to PHP 8 but cannot be re-platformed to Symfony 5.2+ on the same timeline, and you need the dependency to install rather than be forked. In that case: pin v4.0.0, isolate the dependency, do not extend its use to new routes, and put a removal date on the ticket.
• You want a small MIT-licensed reference implementation of route-keyed limiting to read before writing your own — copy the idea, not the dependency.

Look elsewhere — still the default recommendation — when:

• Greenfield or actively maintained codebase: use Symfony's native RateLimiter (5.2+), which covers route-based limits, login throttling, and pluggable storage with an actual support path.
• You are on Laravel: use throttle middleware; there is nothing to evaluate here.
• You need anything beyond the basics: sliding windows, Redis/distributed state, per-user or per-tenant keys, or observability hooks. A PHP 8 constraint does not add surface area.
• You need to run on PHP 8.1, 8.2, or 8.3: the changelog claims "PHP 8" and nothing more. Do not read a floor as a ceiling, and do not assume deprecation-free operation on newer minors without testing.
• You were waiting for a Symfony 5/6 or maintenance-handover signal: v4.0.0 provides neither. One compatibility tag after a long dormancy is a floor, not a commitment, and it does not restore a patch path if a bypass is discovered.
• Security or legal review treats unmaintained code as a finding: still applicable. The release reduces install friction; it does not create a CVE response process.

How to Pitch It (Stakeholders)

Executive summary: The bundle published a major version whose only change is PHP 8 compatibility. That is a maintenance floor, not a revival — no new capability, no Symfony 5/6 support, no security process, and it still duplicates functionality the framework ships natively. Recommendation is unchanged: do not adopt, do not buy — build on the framework's built-in limiter and close the initiative. No budget required. The only action item is a correction to our written decision record.

For engineering: v4.0.0 is a composer-constraint bump for the PHP 8 runtime, shipped as a major version with a one-line changelog — a weak signal about release hygiene, and by itself an argument against depending on it. The 5.2+ RateLimiter component still gives us route-based throttling, login throttling, and swappable storage from a dependency we already run and already support. Adopting this adds an unmaintained, security-adjacent dependency for zero capability gain; the one thing PHP 8 compatibility buys us is the ability to uninstall it more slowly on legacy Symfony 4.4 services, which is a migration-ordering convenience, not a reason to standardize.

Cost and risk: License remains MIT, so purchase cost is still zero — the TCO is maintenance and the absence of a patch path. The v4.0.0 tag reduces one specific risk (a PHP 8 runtime upgrade no longer forces a fork or an emergency migration) and reduces none of the others. No compatibility commitment beyond PHP 8.0 is stated, and a major-version bump for a one-line change is not a stability signal.

Decision requested: Re-approve "pattern yes, package no" — keep route-based throttling on the roadmap, implemented on the native component. Additionally, authorize a two-line correction to the decision record so it reflects the 2020→present release history accurately, and confirm that any service currently pinned to this bundle is tracked as tech debt with an owner and a target removal date rather than treated as newly viable.