Logger Laravel Package

Technical Evaluation

Architecture fit

Alt Three Logger is a thin decorator over Laravel's Monolog binding, built for the Laravel 5.0–5.5 era. Before Laravel 5.6, there was no config/logging.php; Monolog was bound as Psr\Log\LoggerInterface with a fixed handler stack, and the only way to get a named/scoped logger or reach the underlying Monolog instance was to wrap it. This package supplied exactly that: getLogger() to escape to Monolog, newLogger($name) to scope, and a Logger facade so code could type-hint PSR-3 without losing access to those.

That gap closed in Laravel 5.6 (Feb 2018) with named channels, Log::channel(), Log::stack(), and later Log::withContext() / Log::shareContext(). Every capability this package exists to provide is now native. Architecture fit on any supported Laravel version is effectively zero — it adds an indirection layer and a second facade on the one code path (logging) you least want ambiguous.

Integration feasibility

Blocked at dependency resolution, not at code. The package almost certainly pins php: ^7.0 and illuminate/* to the 5.x line (verify against composer.json). Laravel 9–11 require PHP 8.0/8.1+ and Illuminate 9–11; composer require will fail, and --ignore-platform-reqs will not resolve the Illuminate conflict. The only viable host is an already-running legacy 5.x app — which is itself EOL and outside any vendor security process. Zero Packagist dependents corroborates that there is no field-tested failure data to lean on.

Technical risk

• Archived, unmaintined. No CVE triage, no PHP 8 fixes (dynamic-property deprecations, missing return types, PSR-3 3.0's Stringable-typed log() signature).
• Monolog drift. The wrapper exposes Monolog internals (pushHandler, handler naming). Laravel 10/11 ship Monolog 3; the passthrough surface is the brittle seam.
• Central-point exposure. If registered on the global logging/exception path, a throw inside the wrapper can mask the original exception.
• Silent degradation. Scoped names/context lost through delegation causes logs to collapse into the default channel — it fails open, without an error.

Key questions

1. What are the exact require constraints, and confirm there is no replace/provide trick that makes it loadable?
2. Do any portfolio apps still run this in production, and what is their upgrade runway?
3. Does it register a global facade alias Logger that collides with assumptions about Illuminate\Support\Facades\Log?
4. Is there any behavior here that Log::channel() + Log::withContext() cannot reproduce? (Expected: no.)
5. If we must preserve call sites, is a single app-owned shim cheaper than forking a 2018 repo?

Integration Approach

Stack fit

Greenfield or Laravel 8+: do not integrate. Use channels, stacks, and context natively. Brownfield Laravel 5.0–5.5: tolerate it only as an existing frozen dependency and open a removal ticket immediately.

Migration path

1. Inventory call sites: Logger::getLogger(), Logger::newLogger('x'), app('logger'), and any type-hints on the concrete class.
2. Map each scoped name to a config/logging.php channel (daily / stderr / slack / custom monolog driver).
3. Introduce a thin app-owned shim exposing the same method names, delegating to Log::channel() and Log::withContext(). Call sites do not churn.
4. Migrate call sites behind the shim, channel by channel, comparing log output for parity.
5. Remove the Composer requirement, the service provider, and the facade alias; delete the shim last.

Compatibility notes

• Prefer type-hinting Psr\Log\LoggerInterface over the package class so the seam stays swappable.
• If any forked path survives, it must be updated for PSR-3 3.0 Stringable arguments or it will fatal on object interpolation.
• Never keep the alias Logger during transition if anything else assumes Log semantics; use a distinct alias and retire it.

Sequencing

Fold this into the next framework upgrade rather than treating it as standalone work — the upgrade forces the dependency break and amortizes the shim.

• Phase 0 (week 1): constraint audit, call-site inventory, confirm no hidden runtime dependency.
• Phase 1: shim in place, package still installed, zero behavior change, log-volume telemetry per channel.
• Phase 2: migrate call sites with parity checks.
• Phase 3: uninstall, remove provider/alias, delete shim.

Operational Impact

Maintenance

Zero. Archived since 2018, single historical maintainer, no releases, no issue triage. The moment you adopt it, treat it as vendored source you own — and budget forking as a permanent tax on a capability the framework ships free.

Support

No vendor, no community (11 stars, 0 dependents), no documentation beyond a README. Internal expertise is likely zero; escalation is "read the Monolog source," which shifts risk onto whoever is on call.

Scaling

The delegation hop is negligible per call, but the wrapper sits between application code and handler construction, which complicates per-channel level filtering, sampling, and swapping in buffered/handoff handlers for throughput. Native Log::stack() and channel configs are strictly better suited to per-service tuning.

Failure modes

• Install-time (safe, loud): Composer resolution failure in CI.
• Runtime (loud): PSR-3 signature TypeError, Monolog API drift (Call to undefined method), facade unregistered after a config change.
• Silent (dangerous): scoped logger names and context lost through delegation; logs collapse into the default channel with no error.
• Worst case: a throw inside the wrapper on the global exception path masks the original exception.

Ramp-up

Comprehension is ~1 hour — the API is small. The real cost is archaeology: why it was added, what depends on it, and proving removal is safe. That is a short spike plus a log-parity check, not a training plan.

Recommendation: replace, don't integrate. Native Laravel logging fully covers the use case; the only defensible action is a deprecation ticket scoped to the next framework upgrade, executed behind a shim so removal is incremental and reversible.