Nova Activitylog Laravel Package

Technical Evaluation

Architecture fit. sashalenz/nova-activitylog is a thin presentation layer over spatie/laravel-activitylog: it surfaces activity records inside Laravel Nova as a tool/resource (timeline and/or field), so it does not introduce a second audit pipeline. That is the right architecture — the source of truth remains Spatie's activity_log table and model, and Nova is only a read/query surface. The package therefore inherits the constraints of both dependencies: it is only viable if your application is already on Nova and either already uses Spatie activitylog or is willing to adopt it. It is not a standalone audit solution and should not be evaluated as one.

Integration feasibility. Integration is a Composer install plus provider/tool registration and, where relevant, attaching the field to existing Nova resources. Effort is measured in hours, not sprints, for a team already on Nova. The real cost driver is data, not code: retention of activity_log rows, causer/subject morph mapping, and whether historical records exist to backfill.

Technical risk. The release is a major version bump (1.1.1 → 2.0.0) with no substantive release notes — only an auto-generated changelog compare link. Under semver, a major bump is an explicit signal of breaking changes, but the specific breaks are unverified. The most probable breaking axes for a package of this shape are: a Nova major-version requirement (e.g. Nova 4 → 5), a PHP/Laravel floor raise, a rename or removal of the tool/field class or its config keys, or changed default behaviour in filtering/pagination of activity entries. None of these is confirmed by the supplied data. Treat the upgrade as an unquantified-risk change until the diff is read.

Key questions.

1. What is the new composer.json constraint set — Nova, Laravel, PHP, and spatie/laravel-activitylog?
2. Which public symbols were removed or renamed (tool class, field class, config file keys, published migrations/views)?
3. Is there a documented upgrade guide, or is the compare link the entirety of the release communication?
4. Does 2.0.0 alter the database schema or require a republish of migrations/assets?
5. Is the package actively maintained (commit cadence, issue responsiveness, Nova 5 compatibility statement), and what is the maintainer-bus factor given it is a single-author package?
6. Are there first-party or better-supported alternatives we would prefer for a long-lived audit surface?

Integration Approach

Stack fit. Assume Laravel + Nova, Composer-managed, with Spatie activitylog already present or planned. The package slots in as a dev-facing observability tool for admins — useful for support triage, compliance-adjacent change history, and debugging "who changed this record." It is not customer-facing and carries no runtime request-path risk.

Migration path. Do not upgrade in place blind. Sequence:

1. Pin to 1.1.1 on the current branch to freeze known-good behaviour.
2. Read the 1.1.1...2.0.0 diff and the new composer.json before touching code.
3. Branch-upgrade in a disposable environment; run composer update sashalenz/nova-activitylog --with-dependencies and inspect the lockfile delta.
4. Diff published config/assets against the new defaults; re-publish only deliberately.
5. Smoke-test the tool against seeded activity data before merging.

Compatibility. The binding constraint is the Nova major version. If 2.0.0 requires a Nova major you have not adopted, the upgrade is blocked behind a Nova upgrade — a much larger project. Determine this first; it decides whether this is a one-hour or one-quarter item. Secondary constraint: PHP/Laravel floors must align with the rest of the estate.

Sequencing. Resolve the Nova/PHP constraint question → if compatible, upgrade on a branch with a rollback pin → validate tool rendering, filters, and pagination against representative data volume → merge → only then consider adopting any new 2.0.0 capabilities. If the constraints do not align, stay on 1.1.1 and record the package as "version-locked pending Nova upgrade" in the dependency register.

Operational Impact

Maintenance. Low code footprint, but the maintenance burden is dependency-coupled: every Nova or Laravel major will gate this package, and a single-maintainer project may lag. Budget a recurring review at each framework upgrade cycle rather than continuous effort. Track it in the dependency register with an explicit owner.

Support. Internal users are Nova admins and support engineers. The support surface is small: "the activity tab is empty / shows the wrong records" — almost always a causer/subject morph-map or log-name configuration issue rather than a package defect. Document the log-name and morph alias configuration once, in the runbook, and this becomes self-service.

Scaling. Read-path only. The scaling concern is the activity_log table, not the package: unbounded growth degrades the Nova tool's list queries and inflates the database. Mitigate with a retention/pruning policy (Spatie supports cleanup) and appropriate indexes on subject_type/subject_id and created_at. Establish a retention window (e.g. 90–365 days depending on audit obligations) before rollout, not after the table crosses millions of rows.

Failure modes.

• Silent breakage on upgrade: a renamed class or config key causes the Nova tool to fail to register or render blank — no error surfaced to end users. Mitigate with a post-deploy smoke check.
• Missing audit data: logs not written because model observers/LogsActivity were never enabled on the subject models — the package cannot compensate for absent source data. Verify coverage per model.
• Constraint deadlock: package requires a Nova version the platform has not adopted; blocks the upgrade path.
• Schema drift: a republished migration conflicting with an existing customised activity_log table.
• Abandonment: maintainer stops shipping; no security exposure (dev-only surface) but eventual incompatibility with newer Nova.

Ramp-up. Effectively zero for engineers who know Nova — it is a tool registration plus a config file. The non-obvious learning is Spatie's configuration model (log names, causer resolution, attribute change capture), which is where misconfiguration actually occurs. Allocate a half-day of one engineer's time to read the diff, run the upgrade branch, and write the runbook entry. That is the entire realistic onboarding cost.