Stack Trace Laravel Package

Technical Evaluation

Architecture fit. Unchanged. innmind/stack-trace remains a framework-agnostic diagnostic primitive that models a stack trace as typed immutable data on top of innmind/immutable, not a Laravel error handler. It still belongs behind Laravel's exception pipeline (custom report() hook, Monolog processor, aggregation job), never in place of it. The release note does not touch the data model or API surface, so the architectural judgement stands.

Integration feasibility. Materially worse than at the previous assessment. Release 5.1.0 removes PHP 8.4 support. Laravel 11/12 run happily on 8.4, and 8.4 is the default on current base images and CI runners — so on any environment that has already moved to 8.4, this package now fails at install time, not runtime. Two consequences worth stating plainly:

• If our fleet is on 8.3, nothing breaks today, but we are adopting a dependency with a hard ceiling below the current PHP minor. The next PHP upgrade becomes a dependency-blocked upgrade.
• If any part of the fleet is on 8.4, this release is a non-starter and we would be pinned to 5.0.x — an unmaintained branch with the same zero-star, single-maintainer profile, now also guaranteed to receive no fixes.

Technical risk. Raised from High to High-with-a-blocker.

• PHP 8.4 incompatibility. New, concrete, and disqualifying on modern runtimes. The capability delivered (frame filtering, origin detection, fingerprinting) has not increased to compensate.
• Semver discipline failure. Dropping a supported PHP version is a breaking change for affected consumers, yet it shipped as 5.1.0. Anyone using a caret constraint (^5.0) will pull this in on a routine composer update and have their install break or their runtime constraint violated. This is precisely the failure mode the previous assessment warned about, and it has now occurred in the wild — validate for the "pin exactly, no caret" mitigation rather than merely suggesting it.
• Release-train lag. A diagnostics package that cannot run on the current PHP minor will lag every future PHP release. Expect a recurring tax at each upgrade cycle, at exactly the moment we least want a third-party utility in the exception path.
• Zero stars, zero dependents, single maintainer. Unchanged. No issue triage history to inspect, bus factor 1, no community pressure to restore 8.4.
• Ecosystem drag. Unchanged. innmind/immutable still arrives alongside for one diagnostic helper.
• Release metadata anomaly. Still unresolved. The prior future-dated release timestamp was never verified, and a version-numbering decision like this one makes tag and changelog discipline more, not less, worth confirming.
• Reimplementability. Now the dominant consideration. The ~50-line internal implementation was already competitive on value; with a PHP-version ceiling attached, it is simply the better option for most teams.

Key questions for the maintainer/spike.

1. Why was PHP 8.4 dropped — a genuine incompatibility (e.g. an innmind/immutable constraint ceiling, or 8.4 deprecations in the FP primitives), or only missing CI coverage? The answer determines whether 8.4 returns, and when.
2. Is 8.4 support planned for a 5.2.x patch, or is restoration gated behind a 6.0.0 / a new innmind/immutable major?
3. Is 5.0.0 still installable and safe on 8.4, and will it receive security or correctness backports? If not, 8.4 users have no supported version at all.
4. Will the maintainer adopt stricter semver (breaking changes only in majors)? Without that commitment, caret constraints are unsafe permanently.
5. Exact composer.json constraints across 5.0.0 vs 5.1.0 — PHP upper bound, innmind/immutable range, and any psr/log / illuminate/* interaction.
6. Does the package operate on Throwable, getTrace() arrays, or getTraceAsString() text (text parsing is brittle)?
7. Does it traverse chained exceptions (getPrevious()) and expose the origin frame as a first-class concept?
8. Behaviour under zend.exception_ignore_args=1 and with truncated string params?
9. Fixture coverage for internal/closure/eval frames, and green CI on the PHP versions we actually run?
10. Failure mode on an unexpected trace shape — exception or empty result?

Integration Approach

Stack fit. Unchanged. Optional observability tooling in the diagnostics layer only: the report() path, a Monolog processor, an internal error-aggregation job. No reference from controllers, middleware, or domain code.

Migration path. The anti-corruption layer is no longer merely prudent — it is the reason this is still discussable at all. Keep App\Support\StackTrace\TraceInspector with our own TraceFrame / OriginFrame / Fingerprint DTOs, an InnmindTraceInspector implementation, and a one-line container binding. No innmind/immutable type may cross that boundary into application code or fixtures.

Compatibility. This is now the first gate, ahead of any code work:

• Run composer why-not for PHP and innmind/immutable against the real lockfile before anything else.
• Establish the fleet's PHP floor and ceiling explicitly. If 8.4 appears anywhere in scope, either stop here or accept a hard pin to 5.0.x with a documented expiry.
• Pin the exact version in composer.json (5.0.0 or 5.1.0, never ^5.0) and commit the lockfile.
• Confirm 5.1.0 does not also force a psr/log or illuminate/* bump as a side effect of the narrower PHP constraint.
• Confirm Laravel 11's Context facade and this package coexist in the same report() hook without double-logging.

Sequencing. Revised; the decision point moves earlier and gets cheaper.

1. Constraint check (half a day). PHP version matrix across app, CI, and base images, plus a dry-run install in a throwaway branch of both 5.0.0 and 5.1.0. Hard stop if 8.4 is in scope.
2. Maintainer question (async, parallel). Ask the 8.4 question directly. "Missing CI coverage, fix coming" is recoverable; "innmind/immutable ceiling, no plan" is a permanent ceiling.
3. Spike (1–2 days). Feed 20–30 real production traces as fixtures; measure output quality against a hand-rolled array implementation.
4. Decide. Given the release adds no capability and subtracts a supported runtime, the bar is now higher than the previous "within ~80% of quality" test. Unless the package is meaningfully more correct on chained exceptions, internal frames, eval, and closure edge cases, write the internal version. Treat the package as a reference implementation.
5. Adapter + tests. Build the interface and implementation with fixture-based tests covering chained exceptions, vendor frames, internal frames, and argument redaction.
6. Shadow mode. Compute a fingerprint in report(), log it alongside existing output; no alerting or user-facing change for two weeks.
7. Promote. Enable fingerprint-based grouping/dedup once shadow data validates.
8. Re-review. Add a standing item to the dependency review: is there a release that restores 8.4, and has semver discipline improved?

If, and only if, step 1 clears and step 4 passes, proceed at step 5. On the current evidence the expected path ends at step 4 with an internal implementation and this package retained as documentation.

Operational Impact

Maintenance. Assume you own it, and now assume you own a version pin. Zero dependents means no upstream pressure to restore 8.4 or to fix anything else. The single maintainer has already demonstrated a willingness to shed runtime support in a minor release, which is the strongest available signal about future release behaviour. Mitigations: exact pins only, lockfile committed, thin adapter, and a pre-agreed fork-or-replace trigger tightened from the previous "no release in 12 months" to include any PHP minor we run being unsupported for longer than one upgrade cycle — a trigger this release would already have tripped on 8.4.

Support. Unchanged and still thin: no community, no Stack Overflow corpus, no Laravel-adjacent docs. One engineer who has read the source and knows Maybe/Either. Key-person risk on a non-critical feature — acceptable only if documented and paired, and considerably less acceptable when the dependency also caps the platform's PHP version.

Scaling. Unchanged. Cost tracks error rate, not traffic. Two caveats persist: (a) traces with large frame arguments can reach megabytes — enforce zend.exception_ignore_args=1, cap frame count, sample before serialising; (b) fingerprinting every exception during an error storm adds work precisely when the app is already degraded — put a circuit breaker or sampling on the inspector call.

Failure modes.

• Install-time breakage from a caret constraint. The new, demonstrated failure: ^5.0 resolves 5.1.0, which excludes 8.4, and composer update fails in CI or on deploy. Mitigate with exact pins and a lockfile diff review on dependency PRs.
• Dependency-blocked PHP upgrade. The same constraint, one layer up: the platform cannot move to a new PHP minor until this package does. Route PHP upgrades through the dependency review so this cannot be discovered mid-migration.
• Package throws on an unrecognised frame shape → exception inside the exception handler → lost report or white screen. Wrap every call in try/catch, fall back to getTraceAsString().
• PII leakage via frame arguments reaching logs. Redaction belongs in the adapter; never assume the package does it.
• Silent innmind/immutable type errors surfacing only in the reporting path, where tests rarely reach.
• Version drift: an innmind/immutable major resolving at runtime rather than install time.
• Over-grouping: a coarse fingerprint collapses distinct bugs into one alert and quietly degrades detection.

Ramp-up. Unchanged in effort — 1–2 days for a senior PHP engineer on Sequence/Maybe idioms, half a day to read this package's small source, one further day to designate an owner for the adapter. What has changed is the expected return. The honest TPM position is now firmer than before: do not adopt. Write the ~50-line internal implementation, and keep this package as a reference for edge-case handling. A diagnostics nicety that delivers no new capability in 5.1.0, ships a breaking compatibility removal as a minor version, and carries a zero-star single-maintainer supply chain does not justify a permanent dependency — particularly when the cost of the alternative is two days of engineering.