Onelog Bundle Laravel Package

Product Decisions This Supports

• Logging architecture: façade vs. native channels. This package represents the "single unified logger" pattern — one service that fans out to multiple sinks (Sentry, Slack, files, etc.), now with a middleware layer that enriches messages and context before dispatch. Evaluating it forces a useful roadmap question: do we standardize on a first-party abstraction (Laravel's stack channel, Monolog handlers/processors) or introduce a third-party façade layer? The 1.2.0 middleware addition is the strongest argument for the pattern and, simultaneously, evidence we should implement it in-house — Monolog already ships processors/StackHandler for exactly this.
• Build vs. buy for observability plumbing. The honest answer remains "build on what the framework already ships." Monolog's StackHandler/WhatFailureGroupHandler, Psr\Log processors, and Laravel's channel stacking cover ~90% of the use case with zero new dependency risk. The middleware/pre-processing concept in 1.2.0 maps cleanly onto Monolog processors; that is a ~100–200 line in-house addition we would own, not a reason to adopt.
• Vendor and dependency-risk policy. Still a concrete test case for a "minimum viable dependency" gate — maintenance signal, release cadence, security disclosure path, dependents, bus factor. The 1.2.0 release is a single feature commit after years of dormancy, not a maintenance program: no evidence yet of CI, a security policy, a second maintainer, or a supported PHP version matrix. The gate should treat "one recent release" as insufficient to reset a dormancy flag; require a cadence or a stated support policy.
• Supportability and incident-response roadmap. Unified, enriched logging is a prerequisite for on-call runbooks and cross-service correlation. The requirement is real and 1.2.0 sharpens it (context enrichment before fan-out is exactly what correlation needs). The implementation is still not the vehicle — route the requirement to OpenTelemetry or your existing APM vendor, whose SDKs provide enrichment plus sampling, batching, and a support contract.
• Framework-mismatch triage. This remains a Symfony bundle, not a Laravel package, despite surfacing in a Laravel/PHP evaluation context. The new middleware is wired through Symfony's service container and event/kernel conventions; there is no Laravel service provider or config path. Framework fit stays a hard filter in the evaluation rubric, not a soft preference.

When to Consider This Package

Adopt only under a narrow, low-stakes set of conditions:

• You run a legacy Symfony application on a PHP 7.x-era stack, already pinned to this bundle, and need a short, bounded window before replacing it — and you have verified that 1.2.0 actually widens your supported PHP range rather than narrowing it.
• You want a read-only reference for two patterns: multi-sink fan-out (adapter registry, handler dispatch) and pre-dispatch message/context enrichment (middleware chain). Both are readable in an afternoon and writable in roughly 200 lines.
• The logging path is non-critical (dev/staging diagnostics), and you accept no security patching, no stated PHP 8+ guarantee, and no upstream support commitment.

Look elsewhere — decisively — if any of the following hold:

• You are on Laravel. Use config/logging.php with the stack channel plus Monolog processors for enrichment; this bundle's container idioms do not transfer, and a Laravel adapter would be your code to own.
• You need maintained dependencies. One feature release after a long dormancy, 0 dependents, 1 star, bus factor of 1 with no visible co-maintainer, CI, or security policy. A single 1.2.0 tag does not establish a support commitment. Action for the review: re-check the repo for a changelog, tests covering the new middleware, and a composer.json PHP constraint before treating the dormancy flag as cleared.
• You need PHP 8.x / modern framework support. Unverified and unlikely to be covered by a release whose notes describe only a middleware feature; you would be the de facto maintainer of a fork.
• You need structured/correlated logs at scale. Prefer OpenTelemetry (PHP SDK), your APM vendor's SDK (Sentry, Datadog, New Relic), or Monolog + processors + StackHandler. These give you enrichment, trace correlation, sampling, and a support contract.
• You need delivery guarantees. The middleware runs in-process before a synchronous fan-out; it does not add buffering, retries, or backpressure. A slow sink (Slack HTTP) still blocks or drops. Prefer async/buffered handlers or a sidecar (Vector, Fluent Bit).

Verdict: not recommended for adoption. The prior score of 0.235 was driven by maintenance and framework-fit signals, neither of which 1.2.0 materially changes — the release adds a useful capability but no supportability. Treat as a design reference only; note "feature release after dormancy, re-evaluate cadence in 2 quarters" rather than closing the file outright.

How to Pitch It (Stakeholders)

Executives: This is a diligence finding, not a proposal. The package addresses a genuine need — one logging interface across multiple destinations, with a hook to enrich messages before they fan out — and a new 1.2.0 release adds that enrichment middleware. But the maintenance picture is unchanged: one feature release after years of dormancy, one star, no downstream users, no security process, and it targets Symfony rather than our Laravel stack. Adopting it would transfer patch and support responsibility to us for no functional gain over what the framework and our APM vendor already provide. Recommendation: do not adopt; keep the evaluation closed but flagged for a cadence re-check in two quarters, since a single release is not yet a maintenance signal either way.

Engineering: The capability is already in the stack, and 1.2.0 validates the design rather than changing the decision. For enrichment, use Monolog processors (or a small custom processor) ahead of Laravel's stack channel; for correlation and sampling, layer OpenTelemetry or our APM SDK. If we need async delivery to Slack/PagerDuty-style sinks, use a buffered handler or a log sidecar — the new middleware does not add buffering, retries, or backpressure, and it still runs in-process ahead of a synchronous fan-out. If the middleware chain is a useful pattern, copy the concept — a ~200-line reference we own outright — not the dependency. Concrete check before any future re-evaluation: confirm the release ships tests, a PHP version constraint, and a changelog.

Ask: No budget, no dependency. One decision — ratify "framework-native logging + processors + OpenTelemetry" as the standard, and add a maintenance-signal gate to the dependency review checklist (last release and release cadence, dependents, maintainer count, security policy, supported PHP matrix) so candidates get filtered before they reach roadmap discussion. Also amend the gate wording: "a recent release" only counts as a positive signal when paired with evidence of ongoing cadence.