Last Modified Laravel Package

Technical Evaluation

Architecture fit. Unchanged. The package still targets a genuine gap in the Laravel HTTP layer: conditional requests (RFC 7232) are only partially covered by the framework. Laravel ships cache.headers / SetCacheHeaders for Cache-Control, and Symfony's HttpFoundation exposes Response::setEtag() / isNotModified(), but there is no first-class middleware that computes a validator from response content and short-circuits to 304 Not Modified. A middleware in the Illuminate\Contracts\Http\Kernel pipeline remains the correct insertion point. Nothing in 4.4.0 changes the shape of the solution.

Integration feasibility. Unchanged. composer require, register middleware globally or on a read-heavy route group, no migrations, no service-provider state. One engineer, under a day. The gating question is still ownership, not wiring.

Technical risk. Materially reduced but not resolved — revised from High to Moderate.

What 4.4.0 changes:

• The "archived" finding is contradicted, or at least outdated. The release was cut by the maintainer (@andrey-helldar) with a merged community PR (#49), not by an automation bot alone. Either the repository was never archived, or it has been reactivated. This should be re-verified against the repo's current archived flag before we rely on either the old assessment or this one.
• Framework currency is now current. Laravel 13 compatibility means the package is tracking framework majors. The prior concern that "the constraint excludes current framework majors" is retired for Laravel 13 targets. It does not automatically mean our specific Laravel minor is supported — verify the composer.json constraint against our pinned version.

What 4.4.0 does not change:

• Still 8 stars, 0 dependents. Zero production validation, no corpus of bug reports, no evidence about streamed responses, BinaryFileResponse, Octane, or chunked JSON. Adoption signal is unchanged; the compatibility bump is a maintenance signal, not an adoption signal.
• Still single-maintainer, low-bus-factor. One person merging one external PR does not constitute a bus factor.
• Release substance is thin. Of five changes, four are license-year and README/banner image churn from github-actions[bot]; the only functional change is the Laravel 13 constraint widening. There are no bug fixes and no behavioral changes, so every open functional question from the prior assessment survives intact.
• The "alive but barely" cadence is itself a datapoint. Automated cosmetic commits plus occasional compat bumps is the maintenance profile of a hobby project kept on life support, not one with an active bug-fix backlog.
• No CI-matrix evidence in the notes. A compatibility claim without a visible test matrix entry for Laravel 13 is an assertion, not a guarantee. This should be treated as unverified until the workflow file is inspected.
• Metadata anomaly persists. The prior release's future-dated timestamp was flagged as unverified; nothing in 4.4.0 resolves that. Continue to treat release metadata as untrusted for pinning decisions until confirmed.

Key questions. (1)–(6) from the prior assessment remain fully open — this release answers none of them:

1. Which validator does it emit — ETag (content hash), Last-Modified (timestamp), or both — and what is hashed (full body, updated_at, explicit override)?
2. What is the per-request CPU cost of hashing large or streamed payloads, and does it buffer responses it otherwise wouldn't?
3. How does it compose with SetCacheHeaders, Vary, and a CDN edge in front of the app?
4. Does a 304 ever bypass route auth/permission checks that run after the middleware?
5. Does it behave correctly under Laravel Octane / long-lived workers (no request-scoped leakage)?
6. Does it silently overwrite an author-supplied Response::setEtag()?

New questions raised by 4.4.0: 7. Is the repository actually archived — was the prior finding wrong, or was it reactivated, and under what commitment? 8. Does the CI matrix actually include Laravel 13 and our PHP version, or was the constraint widened without a corresponding test lane? 9. Is there a stated support window or EOL policy, now that the package has demonstrated it will track new framework majors?

Integration Approach

Stack fit. Unchanged. Clean fit for cacheable GET endpoints returning application/json or text/html — API list/detail resources, semi-static pages, polling clients. Poor fit for authenticated per-user responses, streaming/downloads, and anything already behind a well-tuned CDN with its own validator strategy.

Migration path. The recommendation softens from "fork-and-own (recommended)" to "adopt with a hard vendor hedge," though both remain viable:

• Adopt-with-hedge (now the default): install the package pinned to 4.4.x, but only behind our own middleware class name so the implementation is swappable without touching route definitions. Retain a vendored fork as a pre-planned contingency rather than the starting point. This is now defensible because the package is demonstrably alive and framework-current, which was the single biggest objection to adoption.
• Fork-and-own (still valid): copy the middleware into an internal http-cache package. The logic is small — compute validator, compare against If-None-Match / If-Modified-Since, emit 304 with correct headers — so reimplementation remains cheaper than carrying a dependency we don't trust for a 30-line behavior. Choose this if the open functional questions (validator source, Octane safety, auth ordering) can't be answered from the source in a code read.
• Adopt-then-fork: unchanged, and still the lowest-commitment way to get a bandwidth measurement before deciding.

Compatibility. Re-verify explicitly — the release note is a claim, not a certificate:

• Confirm the 4.4.0 composer.json constraint covers our exact Laravel minor and PHP version, not just "Laravel 13."
• Confirm the CI workflow now has a Laravel 13 lane; if the constraint was widened without a test lane, treat Laravel 13 support as untested.
• Confirm Octane compatibility if we run Octane — unaddressed by this release.
• Confirm the package does not silently overwrite an author-supplied Response::setEtag().
• Re-check the repo's archived flag and whether a support/EOL policy now exists.

Sequencing. Unchanged, and the release does not justify skipping any step:

1. Spike (1–2 days): 30-line prototype or source read of 4.4.0; unit-test 304/200 paths; confirm Vary and Cache-Control interaction.
2. Shadow mode (1 week): log hash-computation time and would-be 304 rate per route without serving 304.
3. Pilot (2 weeks): enable on 1–3 unauthenticated, high-volume GET routes; measure egress, p95 latency, CPU.
4. Decide: roll out to the cacheable route group, or drop it if the CDN/edge already handles validation.

Because 4.4.0 shipped no behavioral fixes, the spike and shadow phases are not de-risked by this release — they must still run at full scope.

Operational Impact

Maintenance. Downgraded from "we inherit 100% of maintenance" to "shared, but fragile." The maintainer is still shipping framework compatibility, so routine version-bump work is no longer automatically ours. But the release profile — one substantive PR against four automated cosmetic commits — means there is no evidence of an active bug-fix backlog, and no published support window. Budget a named internal owner, a CI job that exercises our Laravel/PHP combination on every framework upgrade, and a scheduled review each Laravel major. Keep the fork contingency warm, not cold.

Support. Improved only marginally. There is now evidence of a responsive maintainer merging external PRs, which makes upstream contribution a plausible escalation path — but there is still no issue triage SLA, no security advisory process, and no dependents to corroborate fixes. Internal escalation must still be defined before production enablement; a 304 bug remains a correctness incident, not a performance one.

Scaling. Unchanged. Benefits scale with payload size and client count (fewer bytes, better mobile latency, lower egress). Costs scale with request count: hashing the full response body is O(body) CPU per request and can dominate on large JSON payloads or high-RPS endpoints. Prefer updated_at-derived validators over body hashing for DB-backed content, and confirm buffering behavior — a middleware that forces buffering on streamed responses can raise memory ceilings under load. Nothing in 4.4.0 touches this.

Failure modes. Unchanged, and none are remediated by a compatibility-only release:

• Stale 304 — content changes without a validator change (e.g., related-model data that doesn't touch the parent's updated_at). Serving stale data is worse than the perf gain; prefer body-hash ETag where staleness risk is high.
• Auth/cache leakage — a 304 returned before authorization is evaluated, or a shared cache storing one user's validator. Enforce Cache-Control: private and correct Vary; never apply to authenticated endpoints without review.
• Validator collision — weak or truncated hashes on high-cardinality content.
• Proxy misbehavior — mismatched ETag semantics at the CDN causing oscillation between 200 and 304.
• Octane state bleed — request-scoped data retained across requests in long-lived workers. Explicitly untested by this release.
• New: false confidence from the compat bump. A Laravel 13 constraint with no visible test lane could invite adoption on the assumption that compatibility was validated. Verify before trusting.

Ramp-up. Unchanged and trivial at the code level — a mid-level Laravel engineer can read and reason about the middleware in a few hours. The organizational ramp-up remains the real work: assigning ownership (now "maintain a fork contingency and a version-bump review" rather than "own the fork outright"), defining eligible routes, and adding 304 rate plus stale-content alarms to observability before the first production request.

Bottom line. Upgraded from "sound idea, unusable dependency" to "sound idea, viable dependency with a maintained hedge." 4.4.0 retires the strongest objection — abandonment — by demonstrating a maintainer actively tracking framework majors, so adopt-with-pinning behind an internal middleware wrapper is now a reasonable default rather than a stopgap. It does not retire the second-strongest objection: zero production validation and one unanswered question about validator semantics, auth ordering, and Octane safety. Ship it only behind measurement, restricted to unauthenticated cacheable GET routes, with a fork contingency kept warm.