Dummy Logger Laravel Package

Technical Evaluation

Architecture fit. The package does exactly one thing: it implements Psr\Log\LoggerInterface as a no-op so that classes can depend on a logging abstraction without forcing a concrete logger into the dependency graph. That is the null-object pattern applied at the logging seam, and it is a legitimate architectural move — particularly for unit tests of services that type-hint PSR-3, for CLI/artisan contexts where logging is meaningless, and for library code that must not impose a logger on its consumers.

The problem is that the pattern is already served by the standard. psr/log ships Psr\Log\NullLogger, and Psr\Log\AbstractLogger reduces a hand-rolled no-op to a single log() method of roughly ten lines. The package description — "so that my own classes can work with a common base" — frames it as a personal utility extracted into a repo, not a library solving a general problem. Against that, 3 stars, 0 dependents, and a score of 0.075 describe a project with no external validation.

Integration feasibility. Composer installation is trivial; the binding constraint is the PSR-3 version. The last release is January 2018, predating psr/log 2.0 and 3.0. psr/log 3.0 added typed interface signatures (string|\Stringable $message, array $context = []): void); a logger written against psr/log ^1.0 does not satisfy the ^3.0 interface and fatals at class load. Modern Laravel — 10/11 with Monolog 3 — resolves psr/log ^3. So the honest feasibility answer is "technically installable, practically incompatible with a current stack." That should be confirmed with a scratch-branch composer require --dry-run rather than reasoned about further.

Technical risk.

• Version lock: usable only on legacy psr/log v1.x trees, which pins us to a shrinking corner of the ecosystem.
• Abandonment: single maintainer, eight years since the last commit, no downstream users generating triage pressure. We inherit support obligation without inheriting the repo.
• Silent log loss: the highest-impact risk. A no-op logger in a misconfigured environment produces no errors and no logs, so the failure is invisible precisely on the paths where observability matters most.
• Supply chain: minimal code surface means minimal exploitability, but also no one watching. The realistic risk is dependency rot, not a CVE.

Key questions.

1. Which psr/log constraint does our application resolve to today, and is anything holding it there?
2. Is the intent a null logger for tests/CLI, or a placeholder default binding until a real logger is wired? The second is an operational hazard, not an integration choice.
3. Are we inheriting this from existing internal code (the "my own classes" framing suggests a predecessor's personal repo)?
4. Is there any requirement that the null logger be a distinct type from Psr\Log\NullLogger — e.g., a type-hinted injection point that can't accept the standard class?
5. Can we vendor the pattern as a ~10-line class or a container binding instead of a dependency?

Verdict: sound in concept, non-viable as a package. Adopt the pattern, not the dependency.

Integration Approach

Stack fit. In Laravel, log is bound to Monolog and the Log facade covers application logging. A PSR-3 dummy is therefore relevant only at narrow seams: service unit tests, dry-run commands, and packages that must not assume a logger. Laravel's container makes the package redundant even there — $this->app->instance(LoggerInterface::class, new NullLogger()) in a test case or service provider achieves the same result with zero dependencies and zero version risk.

Migration path.

1. Already installed: drop the requirement, replace use unreal4u\DummyLogger\... with Psr\Log\NullLogger, delete nothing else. Rename-only change.
2. Evaluated but not installed: don't install. Rely on psr/log, which is already transitively present in every Laravel application via Monolog.
3. Codify the decision: a short ADR or docs/ note recording that null logging is Psr\Log\NullLogger in this codebase, so the question does not resurface each time someone wants a throwaway logger.

Compatibility. Validate the psr/log constraint before anything else — this is the single gate on the whole evaluation. If the app resolves psr/log ^2 or ^3, the package is a non-starter and the analysis ends. If we control an internal package that pulled this in transitively, fix it at that package's next release rather than at the consuming application.

Sequencing. Fold this into whatever ticket already touches the logging seam. It does not warrant a dedicated migration ticket — it is a rename, not a migration, and 0 dependents on the package means our removal breaks nothing upstream or downstream. If the swap is bundled with a real logging change, do the swap first and land it separately so a rollback of one does not roll back the other.

Operational Impact

Maintenance. No viable upstream. Last release January 2018, single author, personal-scope project, no dependents generating patch pressure. Once we depend on it, we own the code without owning the repository — the worst of both arrangements. Any future psr/log incompatibility would be ours to patch in a fork.

Support. No SLA, no issue triage, no security advisory channel. Absolute security exposure is low because a no-op has almost no attack surface, but "unmonitored" is still a dependency-risk category that should be registered under whatever policy governs third-party packages, if only so it appears on a future audit and gets removed.

Scaling. Computationally irrelevant — a no-op logger is the cheapest possible object at any throughput. The scaling concern is organizational: if the dummy logger becomes the default binding in an environment that serves traffic, we lose logs on exactly the failure paths where we need them, and we pay for that during incidents rather than during code review. Null logging must be scoped to test and CLI contexts explicitly, never inherited by default.

Failure modes.

• Loud: psr/log interface mismatch on a modern stack, fatal at boot. Annoying but self-revealing.
• Silent: log records discarded in a context that should have been logging. Detected only when someone reaches for a log line that isn't there.
• Slow: dependency rot. Composer keeps resolving until it doesn't, then someone spends an afternoon on a package nobody remembers adding.

Ramp-up. Minutes for any PHP developer comfortable with PSR-3. The documentation burden is actually negative: there is more to explain about why a bespoke dummy logger exists than about how to use it, and the explanation invites the obvious follow-up — "why not NullLogger?" — which has no good answer.

Recommendation: reject as a dependency; adopt the pattern via Psr\Log\NullLogger, already in the tree of every Laravel application we run.