Dummy Logger Laravel Package

Getting Started

Install it with Composer:

composer require unreal4u/dummy-logger

As of v1.0.1 the package no longer pulls its development dependencies (PHPUnit and friends) into your production install, so the footprint is now essentially just the single logger class plus psr/log. That psr/log requirement exists purely to satisfy Psr\Log\LoggerInterface, so your class can type-hint the standard interface without dragging in Monolog or any real logging backend:

use Psr\Log\LoggerInterface;

class ReportGenerator
{
    public function __construct(private LoggerInterface $logger) {}

    public function generate(): void
    {
        $this->logger->info('generating report'); // swallowed
    }
}

Where to look first: open src/ and confirm the exact class name and namespace (typically unreal4u\DummyLogger\DummyLogger) and whether the constructor takes any arguments. The whole library is one class implementing the PSR-3 methods as no-ops, so reading the source takes two minutes and tells you everything. Then check composer.json for the psr/log constraint — that single line decides whether the package is usable on your stack.

First use case: constructing a collaborator in a unit test or a small CLI script where you need a logger but don't care about output:

$generator = new ReportGenerator(new \unreal4u\DummyLogger\DummyLogger());
$generator->generate();

Implementation Patterns

Null-object injection. The package is a classic null-object: satisfy a dependency contract with an instance that does nothing. Use it wherever a class accepts LoggerInterface but the surrounding context (tests, one-off scripts, migrations) has no logging destination.

Laravel container binding. Bind it as the default when no real logger is configured, or bind it in a test-specific provider:

$this->app->singleton(LoggerInterface::class, fn () => new DummyLogger());

Better yet, use it as a fallback so a missing logger config never fatals:

$this->app->bind(LoggerInterface::class, function ($app) {
    return config('logging.default')
        ? $app->make(\Psr\Log\NullLogger::class) // or your real logger
        : new DummyLogger();
});

Testing seams. Because every call is a no-op, you can instantiate the class under test with zero setup—no log files to clean up, no assertions to write. If a test does need to assert that something was logged, swap in a spy/TestLogger instead (see Gotchas).

Wrapping for observability. If you occasionally need to see what would have been logged, decorate it rather than modify the package:

class RecordingLogger implements LoggerInterface
{
    public array $records = [];
    public function __construct(private LoggerInterface $inner) {}
    public function info(string|\Stringable $m, array $c = []): void {
        $this->records[] = [$m, $c];
    }
    // delegate the rest...
}

Dependency boundary. Prefer type-hinting LoggerInterface in your own code and letting this be one possible implementation—never let the concrete DummyLogger leak into type hints. That keeps the swap to Monolog or NullLogger a one-line change.

Gotchas and Tips

• This is largely superseded by Psr\Log\NullLogger. Since psr/log 1.1.0 (2019), the interface package ships its own NullLogger. If you can depend on psr/log ^1.1, you probably don't need this package at all. Check your psr/log version before adopting.
• v1.0.1 is a packaging release, not a code release. The release notes ("do not require development packages") describe a composer.json change only: dev dependencies moved out of the production require set. No API change, no new methods, no signature work, no constraint bump on psr/log. Treat the upgrade as safe and non-breaking, but do not read it as a sign of active maintenance of the logger itself.
• The core is still effectively frozen at 2018. Expect version constraints targeting psr/log ^1.0. That means it will not satisfy psr/log ^3.0, where LoggerInterface added typed parameters and void return types—the no-op methods here would be signature-incompatible and produce fatal errors during autoload/interface check. Pin or avoid in modern stacks; confirm the constraint in composer.json rather than assuming it changed.
• Leaner installs, but audit status is unchanged. v1.0.1 removes the transitive dev tooling that used to bloat vendor/ and inflate dependency-graph reports, which is a genuine (if small) win for day-to-day installs. The package's own maintenance signal is still weak, so it may continue to flag in composer audit or dependency-check tooling; note that in your rationale if you adopt it for legacy compatibility.
• Silent by design. If logs are missing, that is the point—it will not throw, buffer, or fall back. Don't debug your logging pipeline against this implementation; use a real handler.
• Verify the no-op claim. Confirm in source that methods genuinely do nothing (some "dummy" loggers still error_log() or collect). If it emits anything, tests relying on silence may get noise. The v1.0.1 diff should touch only composer.json — if it touches src/, re-read that file before trusting the release note.
• Method coverage. PSR-3 defines emergency, alert, critical, error, warning, notice, info, debug, log. Confirm all nine exist; older releases occasionally miss the generic log().
• Constructor quirks. If it accepts arguments (some versions take a bool or sink), passing the wrong type in a container binding is an easy silent break—check the signature.
• Extension point. Since it's trivially small, subclass it to build a logging spy for tests, or just implement LoggerInterface yourself—that is often cleaner than pulling a dependency with 3 stars and no maintenance.