Log Bundle Laravel Package

Product Decisions This Supports

• Audit trail / change history features — the Doctrine event logging covers create/update/delete tracking on entities, which underpins "who changed what, when" in admin panels, back-office tooling, and compliance-adjacent workflows.
• Production error visibility — exception logging into a centralized channel supports incident triage, support-desk escalation, and faster debugging without building a bespoke handler.
• Ad-hoc business event logging — the on-demand logging service lets feature teams emit domain events (signup, payment state change) without standing up a full event-subscriber architecture.
• Build vs. buy — the honest framing here remains "adopt vs. write ~100 lines." The scope is narrow enough that replication is cheap; the package's real value is convention, not capability.
• Roadmap scoping — if audit logging is on the roadmap, this package covers only the mechanics. Retention policy, PII redaction, queryable storage, and a review UI remain product work and should be estimated separately.
• Framework fit is a gating decision — despite being a PHP package, this is a Symfony bundle built around Doctrine, not a Laravel package. It does not inform Laravel roadmap decisions and should be excluded from Laravel build-vs-buy comparisons.

When to Consider This Package

Consider it when:

• You are on Symfony + Doctrine ORM and need entity-change and exception logging quickly.
• Your entities are already mapped with PHP attributes — v3.0.0 moved to the Attribute loader, so annotation-mapped models are no longer supported without migration.
• You want a baseline to vendor, fork, or use as a reference implementation rather than a long-term dependency.
• Your team already standardizes on the nti namespace conventions or accepts internal-tooling-style maintenance.
• The on-demand logging API matches how your services currently emit events.

Look elsewhere (or build in-house) when:

• Zero stars, zero dependents, single-source maintenance is disqualifying for your dependency policy — treat this as source code you own, not a supported library.
• You are on Laravel, or non-Doctrine persistence — wrong ecosystem entirely; nothing here transfers.
• You still rely on Doctrine annotations — v3.0.0 drops the annotation reader path; you would need to convert to attributes first, so budget that migration before evaluating the package itself.
• You need structured, queryable audit logs — Doctrine's native event listeners, Gedmo/DoctrineExtensions loggable, or a Monolog handler give more control and better community support.
• You have compliance-grade requirements — tamper-evidence, retention schedules, PII scrubbing, access controls. No evidence this package addresses any of these.
• You require SLA, security responsiveness, or CVE monitoring — none of that exists at 0 dependents.

How to Pitch It (Stakeholders)

For executives: This is a small, unproven open-source logging helper for Symfony applications. It could save a few engineering days on audit and exception logging, but it has effectively zero adoption and a single maintainer, so it carries maintenance risk. The new v3.0.0 release is a maintenance/bug-fix pass, not a feature release — it shows the maintainer is still active, but it also confirms the package breaks across major versions. Recommendation is unchanged: do not adopt it as a dependency. Either replicate the core behavior internally (roughly 1–2 days) or use it only as a reference implementation. The cost of either path is low, so the downside is capped.

For engineering: It's a Symfony bundle that hooks Doctrine lifecycle events and exceptions into a logger, plus an injectable on-demand logging service. v3.0.0 is a breaking, bug-fix-only release: the annotation reader is replaced with the Doctrine Attribute loader, entity manager wiring was fixed, the event subscriber was moved off the deprecated EventListener folder path, and entity-to-table mapping was corrected. Practical implications:

• If we prototype with it, assume attribute mapping only and pin ^3.0 explicitly; any v2 usage is effectively unsupported.
• The fixes suggest the bundle was previously broken or fragile for real installs — expect to find rough edges, and budget time for smoke-testing mapping and listener registration rather than assuming it works.
• Ownership model is unchanged: vendor and pin it, expect to patch it ourselves.
• Core behavior is still straightforward to reproduce with a Doctrine event subscriber and a Monolog channel, which gives us retention, redaction, and storage choices the bundle doesn't make for us. Irrelevant to Laravel work.