Activity Logger Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM needs to surface is a framing error in the request itself: modera/activity-logger-bundle is a Symfony bundle, not a Laravel package. Its integration surface is Symfony's DI container (Extension/CompilerPass), the EventDispatcher, Doctrine ORM listeners, and Symfony's bundle registration in AppKernel/bundles.php. None of that maps onto Laravel's service container, EventServiceProvider, Eloquent, or package discovery. There is no Laravel adapter, no facade, no config publish stub. For a Laravel codebase the architecture fit is effectively zero — adopting it would mean importing a Symfony micro-kernel or hand-porting the listener logic, at which point you are not adopting the package at all.

If the organisation actually runs a legacy Symfony application, the fit is better but still dated: the bundle predates Symfony Flex, autowiring conventions, and the modern attribute-based event listener style.

Integration feasibility. Low. Hard blockers, in order of severity:

Technical risk. High and asymmetric. Signals: 4 stars, 0 dependents, score 0.02, no release in ~9 years. That combination means no production user base, no CVE response, no one to ask when it breaks, and no evidence it ever worked at scale. The "opportunity: 14.7" score is a market-gap heuristic, not a viability signal — a gap here is better read as "nobody wants this," not "untapped demand." An activity/audit log is also a compliance-adjacent component: immature, unpatched code in the audit path is a governance finding waiting to happen.

Key questions for the team.

1. Is the target codebase actually Laravel, or was "Laravel/PHP" shorthand for "a PHP app"? If Laravel, this package is out of scope and the assessment becomes a build-vs-buy comparison against spatie/laravel-activitylog or owen-it/laravel-auditing.
2. If Symfony: which major version, and is there a hard requirement to reuse Modera's log schema/table names?
3. What is the actual requirement — audit trail for compliance, user-facing activity feed, or debugging telemetry? The three have very different retention, immutability, and PII constraints.
4. Who owns the fork if we proceed? A 9-year-stale package is a fork-and-own commitment from day one, not a dependency.

Integration Approach

Stack fit. For a Laravel target, the recommended path is do not integrate; treat the package as a design reference and select a maintained equivalent. Reasonable candidates, mapped to requirement:

• Audit/compliance trail (who changed what, before/after): owen-it/laravel-auditing
• Product activity feed (human-readable events): spatie/laravel-activitylog
• Low-level change capture: Eloquent observers + a custom append-only table

All three are actively maintained, Laravel-native, and have real dependent counts. The functional gap versus Modera's bundle is small; the operational gap is enormous.

Migration path. If there is an existing Modera-produced activity_log-style table in a legacy Symfony system being consolidated into Laravel:

1. Schema-first: capture the existing DDL and row shape; do not let the new library dictate it.
2. Dual-write window: instrument the legacy app to emit into the new store via a queue/message bus rather than sharing a database connection.
3. Read-path cutover after backfill verification, then retire the bundle.

This preserves history without requiring the bundle to run on modern PHP.

Compatibility. The binding constraint is the transitive dependency graph, not the bundle's own code. Any attempt to force-install it will require composer require --ignore-platform-reqs or a replace block — both of which are explicit admissions that the dependency contract is broken and should be documented as such in the ADR.

Sequencing.

1. Spike (≤3 days): clone, attempt install against the real PHP/Symfony/Laravel version, record exact failure points. This produces evidence for the decision record rather than an opinion.
2. Requirements freeze: retention period, mutability (append-only?), PII fields, query patterns (by actor, by subject, by time range).
3. Library selection / build decision against those requirements.
4. Fork decision gate: only if step 1 unexpectedly succeeds and there is a hard schema-reuse requirement. Assign an owner before merging.
5. Instrumentation + backfill, then read-path cutover.

Operational Impact

Maintenance. Effectively 100% internal from day one. There is no upstream to merge from — the "upstream" is a 2016 snapshot. Budget for a named owner, a fork in the org's namespace, and a documented divergence policy. Realistically this is a few days of work per year if it stays on a frozen PHP version, and unbounded if the platform upgrades underneath it.

Support. No vendor, no maintainer response, no issue history of value, no Stack Overflow corpus. Any incident is debugged from source with no external escalation path. For an audit-log component that people only notice during a compliance review, this is the worst support profile: low usage frequency, high consequence when wrong.

Scaling. Activity logging is a write-amplifying, monotonically growing workload and the bundle's era-typical design — synchronous Doctrine listener, per-flush inserts, one row per change — is the pattern that degrades first. Expect:

• Row growth proportional to write traffic, not user count; a batch import can generate millions of rows in minutes.
• Index pressure on (actor, created_at) and (subject_type, subject_id).
• Read queries for "show me this record's history" competing with OLTP traffic on the same primary.

The operational answer is the same regardless of library: asynchronous write path (queue + worker), time-partitioned or separate-database storage, and enforced retention (e.g. 90/365/2555 days by event class). None of that is provided by this bundle.

Failure modes.

1. Platform upgrade breakage — PHP/Symfony/Doctrine minor bumps silently break listener registration; logging stops, nobody notices for weeks because absence of log rows is not an alert.
2. Silent data loss — if the listener throws inside a flush and is swallowed, changes are saved without audit records. The dangerous state is partial audit coverage, which is worse than none for compliance purposes.
3. Request-path coupling — synchronous logging turns a logging failure into a user-facing 500 on a write that would otherwise succeed.
4. PII accumulation — before/after snapshots capture password hashes, tokens, and personal data by default. Retention and redaction must be designed in, not retrofitted.
5. Dependency-supply risk — 2016 transitive packages are a plausible source of an unpatched advisory with no upgrade path inside the constraint set.

Ramp-up. Near-zero learning curve for the API (it is a small bundle) and effectively infinite ramp-up for the implicit knowledge required — there are no docs of substance, no tests to read as specification, and no examples. An engineer picking this up inherits archaeology, not a codebase. By contrast, a maintained Laravel auditing library has docs, tests, an active issue tracker, and public answers to the questions that will actually come up.

Bottom line. The package does not fit the stated target stack, has no adoption evidence, and has been unreleased for nine years. The TPM recommendation is to close this as a non-candidate and redirect the effort into a requirements-driven comparison of maintained Laravel auditing libraries, using this bundle only as a schema reference if legacy log data must be preserved.