User Activity Laravel Package

Technical Evaluation

Recommendation: Do not adopt dp-0/user-activity as a production dependency. Treat it as a reference implementation at most. The archived status is a hard disqualifier for direct consumption in anything with a compliance or uptime obligation.

Architecture fit. The package is a conventional Laravel drop-in: a service provider, a facade, publishable migrations and config, listeners on the framework's auth events, and middleware for page-visit capture. Coupling is low and the surface area is small, so it would slot into a standard Laravel monolith without architectural friction. The problem is fit at the ecosystem level rather than the code level — it occupies exactly the niche served by spatie/laravel-activitylog, which is actively maintained and widely understood. Choosing this package means introducing a bespoke dependency where a de facto standard exists, raising onboarding cost and reducing our ability to move engineers between projects.

Integration feasibility. Technically trivial — composer require, publish config and migrations, register middleware, done in under a day. That ease is a trap: feasibility is not the question. The real question is whether we want to own an unmaintained component, and the honest answer is only if we fork it.

Technical risk.

• Abandonment. Archived repository, last release July 2023. No security patches, no Laravel major-version compatibility work, no issue triage. Every future Laravel upgrade becomes our problem to solve by reading source.
• Version drift. A 2023 release targets the Laravel 10 era. Compatibility with Laravel 11/12 (skeleton changes, service-provider and cast behaviour, PHP 8.2/8.3 requirements) is unverified and should be assumed broken until proven otherwise.
• Correctness assumptions. Likely assumes a single web guard and session auth. Multi-guard, Sanctum/token, multi-tenant, and console/queue contexts where no user is authenticated are classic failure points for this class of package.
• Performance. Page-visit logging on the request path is write amplification. Unbatched, synchronous inserts per request will not survive meaningful traffic.
• Privacy. Logging IP addresses and user agents constitutes personal data under GDPR/CCPA. Retention limits, subject-access/deletion handling, and anonymisation are almost certainly absent from a 12-star package.

Key questions.

1. Is this package already in our codebase anywhere, and in which services?
2. What Laravel and PHP versions must we support over the next 24 months?
3. What is the actual product requirement — audit trail, security forensics, or product analytics? These have very different retention and query needs.
4. Who is the accountable owner if we fork, and what is the budget?
5. Has Legal/Privacy signed off on storing IP and user-agent data, and for how long?
6. What are the read patterns — admin dashboards, exports, per-user timelines — and what volume do we expect?

Integration Approach

Stack fit. Only viable if we are on, or pinned to, Laravel 10.x with PHP 8.1/8.2. On Laravel 11+ assume work is required before first use.

Options.

Migration path. Before any code changes, introduce an internal contract — an ActivityRecorder interface with a single record(event, subject, properties) method — and route all call sites through it. This makes the package an implementation detail rather than an architectural commitment. If the package is already in use, keep its table schema and event naming stable during the swap so historical rows remain queryable; the adapter changes, the data does not. Where both old and new writers must coexist briefly, dual-write behind a feature flag rather than backfilling.

Compatibility. If forking: vendor the source under packages/ with a path repository, pin an exact version, and add the fork to our CI matrix across supported Laravel/PHP combinations. Add an explicit, documented exception to dependency scanning, since upstream advisories will never arrive — this is a risk acceptance that needs a named approver, not a silent suppression.

Sequencing.

1. Inventory existing usage across services (1 day).
2. Agree the event taxonomy and retention policy with Product and Privacy — this is the long pole and gates everything else.
3. Build the ActivityRecorder abstraction with a null/no-op driver.
4. Implement the chosen backing store (Spatie adapter or in-house).
5. Move writes off the request path via queued jobs, with sampling and exclusion rules for noisy routes.
6. Cut over behind a flag; retain the old table read-only for one quarter.
7. Decommission the package and drop the dependency.

Operational Impact

Maintenance. Adopting without forking means zero maintenance and zero patching — which is worse than a maintenance burden, because it is unseen risk accumulation. Forking transfers that burden to us: modest in steady state (a few hours per Laravel major), but it must have a named owner and a place in the upgrade runbook, or it will rot silently.

Support. There is no upstream support and effectively no community: 12 stars means no Stack Overflow corpus, no third-party tutorials, no one to ask. All support is internal source-reading. For a security-adjacent logging component, that is a meaningful tax on incident response.

Scaling. Model the write volume before committing. At 1M page views per day this produces roughly 365M rows per year in a single table. That requires asynchronous writes, table partitioning or time-based retention, and careful indexing for the read paths (per-user timelines, admin dashboards). Aggregate dashboard queries against a hot append-only table are the most likely source of production pain; consider a separate connection or replica for reads.

Failure modes.

• Logging failures propagating into the auth or request path and causing user-facing outages — the recorder must be fail-open and swallow its own exceptions.
• Silent breakage on framework upgrade, discovered only when audit data is missing.
• Unbounded table growth exhausting disk or degrading query performance.
• PII accumulating indefinitely in log rows with no deletion mechanism, creating a compliance liability.
• Duplicate listener registration producing doubled records after a config change.
• Missing activity for API/token-authenticated or queued work, creating false confidence in the audit trail.

Ramp-up. Low. A Laravel engineer can read the whole package in an hour; the idioms are standard. The real ramp-up cost is not the code but the semantics — deciding what constitutes a trackable event, how long to keep it, who can query it, and what "user activity" means for the product. That work is identical regardless of which library we pick, which is precisely why the library choice should default to the maintained, well-understood option.