Laravel Loggable Laravel Package

Technical Evaluation

Architecture fit laravel-loggable is an Eloquent-lifecycle package: you attach a trait to models, and it hooks created/updated/deleted events to write change records "in multiple ways" (driver-style: database, file, etc.). That fits a Laravel monolith or modular monolith where the audit trail is a first-class domain concern and all writes flow through Eloquent.

It does not fit:

• Event-driven or multi-service architectures — logging happens in-process with no outbox, so there's no delivery guarantee to an external sink.
• Systems where writes bypass Eloquent (DB::table(), upsert(), raw SQL, bulk imports) — those paths produce silent audit gaps by design, not by bug.
• Compliance regimes requiring tamper-evidence or append-only guarantees — nothing in a 2020-era trait package provides hash-chaining or WORM storage.

Integration feasibility The gating constraint is not the code, it's the metadata: archived, last release 2020-02-10, 57 stars, health score 0.2175. A February 2020 release predates Laravel 7 and targets roughly PHP 7.2–7.4 / Laravel 5.8–6.x. On Laravel 10/11/12 (PHP 8.1+) the Composer constraint will almost certainly refuse to resolve. Confirm this first — it collapses the build-vs-adopt decision to "adopt" only if you're on a legacy stack.

The upside: the package is small (a trait plus a handful of driver classes) and MIT-licensed, so fork-and-vendor is genuinely cheap — days, not weeks. Treat it as source code you acquire, not a dependency you consume.

Technical risk — High

• Abandonment risk (certain): archived means no security response, no PHP 8.2 deprecation fixes, no Laravel major support. This is not a probability, it's a fact.
• Correctness risk: logging inside model events is not transaction-aware. A rollback after the event fires can leave orphan log rows; conversely, a log write failure can abort the business transaction. Both are audit-integrity failures, which are worse than availability failures because they're discovered during an audit.
• Semantic drift risk: "multiple ways" implies multiple drivers with divergent record shapes. Pick one driver and treat the rest as unsupported surface area.
• Adoption risk: 57 stars means near-zero field-hardening. Edge cases (soft deletes, $casts, JSON columns, pivot writes, mass updates) are unlikely to have been exercised.

Key questions to resolve before any code is written

1. What is the actual regulatory/driver scope — GDPR records-of-processing, SOX change control, internal debugging only? This determines whether immutability is a requirement.
2. Which PHP and Laravel versions are on the target stack, and does composer require resolve at all?
3. Do we need before/after diffs of dirty attributes only, or full row snapshots? Snapshot approach has very different storage economics.
4. Do we need actor context (user, IP, request ID, tenant), and is that PII we must redact from the log payload?
5. Retention and deletion requirements — can an audit row ever be deleted, and does GDPR erasure apply to it?
6. Have we evaluated spatie/laravel-activitylog or owen-it/laravel-auditing against these requirements?

Integration Approach

Stack fit Binary. If the app is on Laravel ≤6 / PHP ≤7.4, fit is straightforward and the only work is hardening. If the app is on Laravel 9+, fit is zero without a fork — do not attempt --ignore-platform-reqs, that just defers a runtime failure into production.

Migration path Recommendation, in priority order:

1. Requirements-first re-evaluation. Write the audit requirements above, then benchmark the two maintained alternatives. In most cases this package is not selected.
2. If it wins on fit (e.g., a specific driver or payload shape the alternatives don't offer), fork it: copy to packages/laravel-loggable, register as a Composer path repository, and take ownership.
3. Do not use it as a live VCS/dev-master dependency against an archived repo.

Compatibility work for a fork

• Relax composer.json constraints to php: ^8.1|^8.2 and laravel/framework: ^10|^11.
• Fix PHP 8.2 deprecations — dynamic property creation is the most likely offender in a 2020 codebase.
• Verify Laravel internal API usage still exists: getDirty(), getOriginal(), getChanges(), event dispatcher signatures, HasAttributes.
• Confirm the storage driver handles JSON columns on your DB engine (MySQL 5.7+/8, Postgres jsonb), and that diff payloads are size-capped.
• Add a test suite if none exists — this is non-negotiable when you own the code.

Sequencing

1. Spike branch: install (or fork) + log one high-churn model end-to-end.
2. Schema design: audit table with model type/ID, event, actor, tenant, diff payload, request correlation ID, timestamp — and decide partitioning before the table gets large.
3. Wire the trait/observer behind a feature flag on one or two models only.
4. Dual-write alongside existing logging; diff the two streams for a sprint to validate completeness.
5. Explicitly enumerate and patch the write paths that bypass Eloquent, or document them as out-of-scope.
6. Cutover, then remove legacy logging.

Operational Impact

Maintenance Ownership transfers entirely to your team. Budget roughly 1–2 engineer-days per Laravel major upgrade plus ad-hoc PHP deprecation fixes, and accept that there is no upstream to patch a CVE. Contrast this with a maintained alternative where the same budget buys a version bump.

Support No maintainer, no issue triage, no community. Internal runbook and inline documentation of the driver configuration are mandatory — the "multiple ways" config surface is the part future engineers will misconfigure.

Scaling The audit table becomes the fastest-growing table in the schema — commonly 5–20× the write volume of its source models, and diff payloads make rows wide. Three consequences:

• Partition by time or model type, and implement retention/pruning from day one rather than retrofitting under pressure.
• Consider an isolated database connection so audit write latency and lock contention don't degrade the primary.
• Prefer queued/asynchronous writes for throughput — but recognize that queuing breaks ordering and atomicity with the source transaction. Choose deliberately.

Failure modes, ranked by severity

1. Log write failure aborts the business transaction — an audit package taking down checkout. Wrap driver calls defensively and fail-open for non-regulatory use cases; fail-closed only if the compliance requirement genuinely demands it.
2. Silent audit gaps from mass updates, upsert, seeders, queue jobs using DB::table(), and soft-delete restores. Unknowable after the fact; enumerate paths up front.
3. Transaction rollback desynchronization — log rows written for changes that never committed, or committed changes whose logs were lost.
4. Unbounded table growth → disk pressure, slow queries, longer backups.
5. Payload bloat — logging diffs of large text or base64 blob columns, and PII leaking into an immutable table you can't easily redact.

Ramp-up Low technical ramp for any Laravel developer — traits and model observers are familiar patterns, roughly half a day. The real ramp is organizational: defining what "logged" means, which models are in scope, and who owns retention. That work is the same regardless of package, which is precisely why the package choice should default to the maintained option.