Dummy Logger Laravel Package

Product Decisions This Supports

• Build vs. buy on a logging abstraction. This is a "null object" for PSR-3: a logger that accepts every log call and does nothing. The only real decision it informs is whether to pull a dependency for a no-op or write the ~20 lines yourself. For almost every team, that decision resolves to build.
• Default injection point for SDKs and shared libraries. If we publish a PHP package that accepts a LoggerInterface but must work with zero configuration, we need a default that never writes, never throws, and never requires the consumer to install Monolog. That is the legitimate use case behind this package.
• Test doubles and silent paths. A no-op logger keeps unit tests free of log output and lets us exercise code paths that log without asserting on them. (In Laravel we'd normally reach for Log::spy() or a mock, so this is a narrow benefit.)
• Bootstrap and feature-flag scenarios. Useful where logging must be suppressed before configuration is loaded, or gated behind a runtime flag/kill switch — e.g., a queue worker or CLI tool that shouldn't emit anything in certain modes.
• Roadmap impact: negligible. This is infrastructure plumbing, not a feature. It should never appear on a roadmap as a deliverable, only as an implementation note inside another work item. The package's "opportunity" score reflects a small, well-defined niche, not strategic value.
• Not supported: observability, compliance, or audit trails. Anything requiring structured logs, retention, or traceability is explicitly out of scope — this package is designed to discard data.

What changed in v1.0.1: the release moves development packages out of the consumer-facing require block, so downstream installs no longer pull test tooling. That is a genuine packaging-hygiene fix — it shrinks the transitive dependency footprint and removes the most obvious supply-chain objection — but it changes no behavior, adds no feature, and does not touch interface signatures or PHP version constraints.

Recommendation: Do not adopt as a Composer dependency. Use Psr\Log\NullLogger (ships with psr/log itself) or copy the pattern into an internal class. The dependency-footprint objection is now weaker; the redundancy and maintenance objections are unchanged.

When to Consider This Package

Consider it only if all of the following hold:

• You are publishing a standalone PHP library (not a Laravel app) that must remain backend-agnostic and needs a zero-dependency default logger.
• You have verified psr/log's NullLogger is unavailable or unsuitable in your constraint set — which is rare, since it has existed since psr/log 1.0.
• You accept a single-maintainer, 3-star, zero-dependent package as part of your supply chain — now marginally more defensible, since v1.0.1 removed dev tooling from the runtime requirement set, but still a single-maintainer artifact with no security disclosure process.

Adoption criteria to check before any use:

• PHP version constraints — the original release was January 2018 and v1.0.1 is a composer.json-only patch; verify it installs cleanly on PHP 8.1+ and alongside current psr/log versions. Expect composer require conflicts. The release notes give no indication this was tested on modern PHP.
• PSR-3 version — confirm the implemented interface matches psr/log v2/v3 signatures (return types on log(), LoggerInterface typing). A 2018 implementation likely targets v1, and a dev-dependency cleanup does not change that. This remains the most likely blocker.
• Maintenance and security posture — one packaging patch after a seven-year gap is a housekeeping commit, not a maintenance commitment. No dependents, no issue activity, no disclosure process. Still treat it as effectively unmaintained.
• License compatibility — verify against your distribution model.

Look elsewhere when:

• You are in Laravel — configure a log channel backed by Monolog\Handler\NullHandler, or use Log::spy() in tests. No third-party package needed.
• You need any real logging — use Monolog with a proper handler stack.
• Your team has supply-chain review, SBOM, or compliance requirements — the v1.0.1 cleanup helps, but an abandoned micro-dependency is still a poor trade for code you can write in five minutes.
• You target modern PHP and want predictable Composer resolution.

How to Pitch It (Stakeholders)

For executives: This is a tiny, single-purpose utility that implements a standard logging interface but discards every message. It has no business logic, no feature surface, and no strategic value — it exists only so a library can accept a logger without forcing one on its users. The recent v1.0.1 release is a housekeeping patch that stops shipping test tooling to consumers; it is not a sign of renewed investment. The package still has three stars, no downstream dependents, and a single maintainer who made one small commit after seven years of silence. Adopting it would add a third-party dependency, a maintenance review, and a future migration for roughly twenty lines of code. Recommendation: do not add the dependency; replicate the behavior in-house or use the null logger already shipped in the PSR-3 standard.

For engineering: The package is a PSR-3 no-op logger. psr/log already provides Psr\Log\NullLogger, which does exactly this and comes in with a dependency you almost certainly have anyway. v1.0.1 only moves dev packages out of require — useful, because the old manifest would have dragged PHPUnit-era tooling into our install graph, but it says nothing about runtime compatibility. The implementation still predates PSR-3 v2/v3 return types, so expect signature mismatches and possible constraint conflicts on PHP 8.1+. If we evaluate it at all, do so with a throwaway Composer script that resolves against our actual psr/log version before anyone spends review time. In Laravel, use a Monolog NullHandler channel or a mocked facade in tests. If we genuinely need a bespoke default, a small internal NullLogger class costs less to write and review than an external dependency, and it keeps our supply chain and Composer graph clean.

Bottom line: Low value, low risk, and now slightly cleaner packaging — but still no reason to exist alongside Psr\Log\NullLogger. Decline adoption; use the standard library equivalent.