Laravel Tracer Laravel Package

Product Decisions This Supports

• Whether an audit/provenance trail is worth building at all. The package's core idea — stamping each model write with a tracer (the user, job, or parent model that caused it) via a polymorphic tracer_type / tracer_id pair — directly informs the "do we need to answer who or what changed this row?" question that shows up in support, billing disputes, and incident reviews.
• Build vs. buy vs. skip for auditing. It represents the minimal end of the spectrum: no diffs, no old/new values, no UI, no retention policy. Comparing it against spatie/laravel-activitylog and owen-it/laravel-auditing clarifies scope: are you buying "provenance" (cheap) or "audit log" (expensive)?
• Scoping the provenance feature for the roadmap. Useful mental model for concrete use cases: attributing background-job writes, tracing a child record back to its parent aggregate (line item → order → customer), and tagging rows with the request/actor that produced them.
• An updated — but still weak — signal for the dependency roster. v0.3.3 ("PHP 8.1 + L9") moves this from archived/dead to dormant but technically alive: someone is still able to cut a compatibility tag. That is a meaningful correction to the prior assessment (which said no release since August 2022 and an archived repo), but it is a version-compatibility bump, not a feature, fix, or maintenance commitment. 4 stars and 0 known dependents are unchanged. The dependency-roster conclusion stays: we would own this code if we adopted it.
• Fork-or-reimplement triage. Because it is MIT-licensed, the realistic product option is not "adopt" but "read it, then reimplement the ~1 migration + 1 trait in-house," which is a day of engineering, not a dependency decision. v0.3.3 does not change the size of that day, and it does not add capability we would otherwise have to build.
• Upgrade-window planning. The bump raises the supported ceiling to PHP 8.1 / Laravel 9. For a service pinned to L9 it extends the usable window; for anything already on Laravel 10/11/12 it is still behind, and there is no evidence of a cadence that will close that gap.

When to Consider This Package

Consider it only in this narrow case:

• You are maintaining an existing Laravel application that already depends on it, and the cost of removal now exceeds the cost of pinning/vendoring it.
• You need exactly one thing: passive tracer_type/tracer_id columns populated on created/updated, with no field-level history, no querying UI, and no retention requirements.
• Your application runs PHP 8.1 / Laravel 9 — the combinations v0.3.3 explicitly targets. On Laravel 10+ treat compatibility as unverified and vendor or fork before relying on it.
• You are prepared to fork it into your own namespace. The release shows the project is not formally dead, but one compatibility tag in three years is not a patch cadence you can escalate a security issue through.

Look elsewhere — or build in-house — when any of the following hold:

• You need old/new value diffs, per-field history, or a reviewable timeline → spatie/laravel-activitylog or owen-it/laravel-auditing.
• You need retention, tamper-evidence, tenant scoping, PII redaction, or compliance reporting — none of which this addresses, and none of which a compatibility-only release suggests it will grow.
• You need active maintenance, security patching, or current Laravel-version currency — v0.3.3 improves the currency story by exactly one major version and adds no security or support commitment.
• You want a lineage graph rather than a single pointer. One morph column answers "who touched this row"; it does not answer "what chain of events produced it."
• Your team is small enough that one bespoke trait plus one migration is cheaper than a supply-chain review of a barely-maintained dependency. For this scope of functionality, it almost always is.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. The v0.3.3 release does not change this — but it does soften the "abandoned" framing.

protonemedia/laravel-tracer shipped v0.3.3, which by its own notes is a compatibility bump for PHP 8.1 and Laravel 9. That is worth acknowledging: the project is dormant rather than dead, and the previously stated "no release since 2022 / archived" characterisation should be corrected in any deck or ticket that cited it. What has not changed is everything that drove the decision. Adoption remains negligible (4 stars, 0 tracked dependents), the release adds no capability — no diffs, no history UI, no retention or redaction — and one tag in three years is not a maintenance relationship anyone can open a security ticket against. Adopting still transfers full ownership to us on day one, and at that point we are maintaining a dependency to avoid writing roughly one migration and one Eloquent trait.

The underlying idea is still worth a roadmap line. "Which actor or process created this record?" is a recurring question from support, finance, and incident response, and it is cheap to satisfy — either with a small in-house trait or, if we want diffs and a reviewable history, with a maintained package like spatie/laravel-activitylog. The decision to make is provenance-only vs. full audit log, not this package vs. nothing. The release slightly improves the odds that a fork would start from a Laravel-9-compatible base; it does not improve the case for depending on it.

Suggested next step: confirm whether any existing service already pulls this in (0 tracked dependents suggests not). If one does and it runs Laravel 9, pin to v0.3.3 and schedule extraction to an in-house trait alongside the next framework upgrade. If none does, close this out and log the provenance requirement against the auditing evaluation instead.