Log Bundle Laravel Package

Technical Evaluation

Architecture fit. Unchanged at the category level: despite the "Laravel/PHP package" billing, nti/log-bundle remains a Symfony bundle, not a Laravel package — *Bundle class, DependencyInjection/*Extension, service definitions, and framework lifecycle hooks that do not exist in Laravel. v3.0.0 does not alter the architectural split. What it does change is the portability profile of the payload, in two directions. On the positive side, the release notes describe fixes ("eventSubscriber on eventListener folder deprecation", "entity manager inclusion") that modernize the bundle's wiring — which, if confirmed in source, means the listener classes are now closer to plain Doctrine\Common\EventSubscriber implementations with less Symfony glue to strip during a fork. On the negative side, the annotation→attribute migration is a Doctrine mapping-strategy commitment, not a logging feature. A Symfony or Doctrine-enabled Laravel app using annotations (or mixed mapping) now sits on a different contract than the one v3.0.0 targets.

Integration feasibility. For a Symfony + Doctrine target, feasibility is materially better than at v1/v2: v3.0.0 is the version to evaluate, and the attribute-loader fix removes a class of runtime breakage on PHP 8 projects where annotations have been deprecated (Doctrine ORM 2.x) or removed (ORM 3.x). For a Laravel + Doctrine target, the port path is unchanged in shape but the source-of-truth changes: you should fork/branch from v3.0.0, not from main, because the entity-manager inclusion fix and the attribute-driver change likely constitute the difference between "works" and "silently does nothing." For a Laravel + Eloquent target, feasibility remains near-zero — v3.0.0 modernizes the Doctrine half, which is the half that does not apply.

Technical risk. Still high overall, with the risk mix rearranged. Mitigated slightly: the existence of a v3.0.0 with substantive fixes is a weak-but-real liveness signal — this is not a single-commit repo that was abandoned at publication. Someone is tracking upstream Doctrine/Symfony deprecations. Newly introduced: the major-version bump is itself a breaking change. Annotation-based consumers cannot assume they are supported; attribute-based mapping is now the assumed path, and the release notes imply that v2.x was broken in production-relevant ways (entity manager not properly included, entity↔table relation broken, subscriber deprecated). That reinforces rather than relieves the "no external validation" concern — there is no issue traffic, changelog, or test report confirming these fixes work outside the author's environment. Unchanged: zero stars, zero dependents, no third-party smoke test; nti/ namespace strongly suggests internal tooling published publicly; LICENSE/IP, transitive symfony/* pull-in, and the Doctrine-listener PII exposure risk (change sets, SQL parameters reaching log storage) all still apply.

Key questions to answer before committing engineering time. (Revised to reflect v3.0.0.)

• What is the declared license, and who owns the copyright? (Unchanged, still the first gate.)
• Does v3.0.0 require PHP 8.0+ (attributes) — and does it also require Doctrine ORM 2.9+ with the attribute driver, or has it moved to ORM 3.x? What are the exact composer.json constraints on php, symfony/*, doctrine/orm, doctrine/dbal?
• Is the annotation driver dropped entirely or still supported as a fallback? This determines whether annotation-based consumers can upgrade at all.
• What specifically was the "entity manager inclusion" bug — was the EM missing from the listener's constructor, and does the fix now couple the listener to a specific container wiring that must be replaced in a Laravel ServiceProvider?
• What does "eventSubscriber on eventListener folder deprecation" refer to — Symfony's EventDispatcher namespace moves, Doctrine's EventSubscriber interface, or the package's own file layout? It signals which Symfony major version(s) are in scope.
• Does v3.0.0 implement PSR-3 LoggerInterface, or a bespoke abstraction? (Unchanged, still unanswered.)
• What is the log transport, and does the entity↔table relation fix touch a shipped schema/migration?
• Does it serialize Doctrine change sets and parameters verbatim (PII), and is redaction/allowlisting now present?
• Is there CI, a test suite, a changelog, and tag history? Two releases is better than one but still not cadence.

Integration Approach

Stack fit. The decision tree is unchanged; the version pinning is. Symfony + Doctrine: fit is good and improved — target v3.0.0 explicitly, and treat v2.x as unsupported. Laravel + Doctrine: fit remains moderate at the concept level; fork from the v3.0.0 tag. Laravel + Eloquent: fit remains essentially zero; only the exception-listener half is portable, and it still does not justify a dependency.

Migration path (Laravel target, recommended). Shape unchanged, source changes:

1. License and code audit against the v3.0.0 tag — confirm no obfuscation, no network egress, no phone-home.
2. Extract the on-demand logging service and exception handler logic into app/Logging/.
3. Reimplement the Doctrine subscriber against Doctrine\Common\EventSubscriber; register inside a ServiceProvider. The v3.0.0 entity-manager fix may simplify this — the listener likely expects a plain EntityManagerInterface rather than a container lookup — which is a small improvement to port friction.
4. Bind as singleton, inject Psr\Log\LoggerInterface.
5. Contract-test log record shape (level, channel, context keys) against fixtures. Critical at v3.0.0: the mapping-strategy change may alter what fields appear in context (entity metadata, table name). Re-baseline the fixtures; do not carry v2-era assertions forward.
6. If your Doctrine entities use annotations, either migrate them to attributes or branch the fork to retain annotation support. Do not assume the package will re-add it.

Compatibility. Gating constraints have tightened. Expect a PHP 8.0+ floor (attributes are the tell), a Doctrine ORM minor/major floor consistent with attribute support (2.9+, possibly 3.x), and Symfony component versions aligned to whichever deprecation the eventSubscriber fix addresses. In a Laravel context, the symfony/* conflict risk is unchanged. A new compatibility decision: if your Doctrine entities are annotation-mapped, v3.0.0 is not a drop-in and the migration cost shifts from the package to your entity layer — which is a much larger blast radius than a logging utility should ever be allowed to dictate.

Sequencing. Unchanged in order with one added step:

1. License/audit gate against v3.0.0.
2. Mapping-strategy compatibility check — inventory your Doctrine entities' mapping driver. If annotation-only, stop and reassess.
3. Sandbox spike: install v3.0.0, generate a throw, perform a Doctrine write, capture real output, confirm entity/table relation resolves.
4. Go/no-go: fork-and-adapt vs. build-native (~1–2 days with Monolog + a Doctrine subscriber, and you own it).
5. Feature-flag on one low-risk service.
6. Staging validation of volume, latency delta, redaction.
7. Explicit decision date.

Operational Impact

Maintenance. Still the dominant cost, though the calculus shifted slightly. The v3.0.0 release demonstrates at least intermittent upstream maintenance — enough to suggest you are not adopting a corpse, not enough to assume a support relationship. Two releases with a major version bump is more risk of breaking change per release than a stable, quiet library; major bumps concentrate upgrade work into a single event and signal that the API surface is not yet settled. Forking still means you own a permanent divergence, and every future Doctrine upgrade lands on you. Budget the same 2–4 hours per month floor, plus a one-time v3 migration assessment if you had already scoped v2. Assign a named internal owner — unchanged and still the single most common failure of third-party logging.

Support. Unchanged. No vendor SLA, no issue-traffic signal, likely no documentation beyond the README. The release notes are terse and written for insiders ("Fix issue to make relation…" is not a description a third party can act on), which is itself diagnostic: the maintainers are not writing for external consumers. Every support event is internal. The extract-and-own path remains the only one where your engineers can debug at 3 a.m.

Scaling. Unchanged and independent of the release. Doctrine event logging scales badly by default — per-flush events on high-write services multiply log volume well beyond request-level logging, and synchronous handlers add latency to the write transaction. Still require: asynchronous queue-backed transport, sampling/level gating, and a retention policy. If the transport is a DB table, the v3.0.0 "relation between entity and database table" fix makes it more likely that schema writes now actually occur where they previously silently failed — which increases, not decreases, the need for a TTL.

Failure modes to design against explicitly.

• Exception-handler swallow: unchanged; wrap the handler body and degrade to a fallback.
• Recursive logging: unchanged; the log writer must not participate in the listened-to event cycle.
• Transport outage: unchanged; logging must never be on the critical path.
• PII leakage: unchanged; redact before write, and newly re-verify after v3.0.0, because changed metadata resolution can change which fields land in the log context.
• Disk/table exhaustion: unchanged; the entity↔table fix raises the odds that DB-backed logging now works, so retention/TTL is more urgent, not less.
• Silent failure — now more acute. v2.x appears to have been broken in ways that produced no logs (entity manager inclusion, subscriber deprecation). Upgrading to v3.0.0 without a health assertion repeats that pattern in the opposite direction: you cannot distinguish "fixed and logging" from "still silently inert" without a known-event → known-record test.
• Mapping-driver mismatch: if the attribute-driver requirement is strict and your entities are annotated, failure may surface as missing entity metadata rather than a log error — diagnoseable but slow.

Ramp-up. Consuming the on-demand service: under an hour. Understanding a v3 fork: 1–2 days for a mid-level PHP engineer, plus the prerequisite knowledge — Doctrine's event lifecycle (onFlush vs postFlush, change-set computation) and now Doctrine attribute mapping and the annotation→attribute migration, which a typical Laravel developer will not carry. The prerequisite list got slightly longer, not shorter. Factor it into the estimate, and note that the most commonly underestimated line item — the domain-knowledge gap — is the one v3.0.0 widened.