Logger Extra Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (and the answer is "build"): This is a candidate for one narrow decision — do we adopt an off-the-shelf bundle for logging enrichment (correlation IDs, user/tenant context on every log record, exception formatting), or do we write ~50–150 lines of Monolog processor/handler code ourselves? Given 4 stars, 0 dependents, and a last release of October 2014, the in-house option is cheaper to own and carries no abandonment risk. Budget it as a small spike, not a project.
• Platform-fit gate: The package is a Symfony 2 bundle, not a Laravel package, despite being surfaced in a Laravel/PHP scan. That rules it out for a Laravel roadmap by default. The only legitimate product context is a legacy Symfony 2.x estate — and in that context the decision it informs is "what is our exit plan," not "should we adopt."
• Roadmap input for modernization: The package's abandonment is a useful forcing function. If it already appears in a composer.json anywhere in the portfolio, that's a concrete data point for the framework-upgrade business case: it will not survive a Symfony 3+/4+/5+/6+/7+ migration, and its functionality must be re-homed onto MonologBundle + first-party processors.
• Observability use cases it nominally covers: request/correlation IDs across services, per-user and per-tenant log tagging, richer exception context (stack/request metadata), and log routing to extra handlers. These are real product needs — the need is valid, the package is not the answer.
• Vendor-risk triage: Treat a score of ~1.03, 4 stars, 0 dependents, and a 10+ year-old release as a red-flag dependency. Use it as a worked example in your dependency-governance policy: any package with no release in 24 months and zero dependents requires an explicit owner and an exit plan before it ships.

When to Consider This Package

Consider it only when all of the following are true:

• You are maintaining an existing Symfony 2.x application on PHP 5.x that already has this bundle installed and working.
• You are doing a short-horizon bug fix or security patch and cannot fund a logging refactor in the current cycle.
• You have a named owner and a dated ticket to replace it — i.e., you are tolerating it, not adopting it.

Look elsewhere (essentially always) when:

• You are on Laravel. This is not a Laravel package; there is no service provider, no Laravel-idiomatic config, and no compatibility story. Use Laravel's native logging (Monolog channels, Log::withContext(), Context middleware) or a maintained package such as spatie/laravel-activitylog for audit trails.
• You are on Symfony 3+. Use symfony/monolog-bundle with first-party ProcessorInterface implementations. Anything this bundle did can be done in a few dozen lines of config and one or two processors.
• You need structured/observability-grade logging. Go to OpenTelemetry PHP, Sentry's Symfony/Laravel SDK, or a Monolog formatter that emits JSON with trace/span IDs. A 2014 bundle predates all of this.
• You need any form of maintenance guarantee. No security response, no PHP 8 compatibility, no upstream fixes. Under a modern SCA/SBOM policy this fails outright.
• You are greenfield. There is no scenario in which a new product should take this dependency.

How to Pitch It (Stakeholders)

For executives — one line: This is a 10-year-abandoned Symfony 2 add-on with 4 GitHub stars and zero known dependents; it is not a strategic dependency, and the correct decision is do not adopt, with a small cleanup effort if it already exists in our codebase.

For engineering leadership: The underlying capability — putting request IDs, user/tenant context, and richer exception data on every log line — is worth having, and it is a half-day of Monolog processor work. Buying it from an unmaintained 2014 bundle trades a half-day of build for unbounded maintenance, upgrade, and security risk, including a hard blocker on any Symfony major-version migration.

For the engineering team: Do not add this to any composer.json. If it is already present, file a ticket to replace it with monolog-bundle processors and native context (or the equivalent Laravel Log::withContext() middleware), and track it under dependency-governance hygiene rather than as a feature.

Framing the recommendation: Low effort, low cost, clear upside — this is a cheap "no" with a cheap remediation, which makes it an easy win to cite when socializing stricter dependency-review standards.