Console Log Laravel Package

Getting Started

archtechx/console-log is a small utility for surfacing Laravel log records on the console/STDOUT instead of (or alongside) the file-based channels. It is the kind of package you install once, wire into config/logging.php, and then never think about again — which is exactly what you want.

Minimum steps:

1. composer require archtechx/console-log
   • As of v0.1.4 this requires Laravel 9+. Laravel 8 support was removed and dependency constraints were corrected. If you're still on L8, pin 0.1.3 explicitly ("archtechx/console-log": "0.1.3") or skip the package — Composer will otherwise resolve to a version that fails your platform requirements.
2. Publish the config if the package ships one: php artisan vendor:publish --tag="console-log-config". Read the file before touching anything else — that is where channel name, level, and formatting behaviour are defined.
3. Register the channel in config/logging.php (or use the package's own channel entry if it auto-registers), then point the environments you care about at it:

'channels' => [
    'console' => [
        'driver' => 'console', // name defined by the package
        'level'  => env('LOG_LEVEL', 'debug'),
    ],
],

4. First use case: containerised / queue-worker environments. Set LOG_CHANNEL=console (or add it to a stack) in staging and in your Docker/Kubernetes deploy so docker logs and your log aggregator pick records up from STDOUT rather than from a storage/logs/laravel.log nobody can reach inside the container.

Sanity check before going further: run php artisan tinker and Log::channel('console')->info('hello'). If you see the line on the terminal, you're wired correctly.

Implementation Patterns

Dedicated channel, not the default. Keep stack/daily as your default channel and call the console channel explicitly, or add it as a second member of a stack. Silently switching the default means losing rotation and file-based retention for local development.

'channels' => [
    'stack' => [
        'driver'   => 'stack',
        'channels' => ['daily', 'console'],
        'ignore_exceptions' => false,
    ],
],

Environment-driven selection. The cleanest integration is to leave application code untouched and drive it entirely from env: LOG_CHANNEL=stack locally, LOG_CHANNEL=console in the container image's runtime config. No Log::channel(...) calls scattered through the codebase.

Artisan command output. This is where the package earns its keep: long-running commands and scheduled jobs emit structured log lines into whatever collects process output (Supervisor, systemd journal, ECS/K8s log driver). You get timestamps, levels, and context arrays without hand-rolling $this->info() everywhere — and you keep context:

Log::channel('console')->info('Import finished', [
    'rows'     => $count,
    'duration' => $elapsed,
]);

Pair it with verbosity. Let console commands keep $this->output->writeln() for human-facing progress, and reserve the log channel for machine-collected records. Mixing the two produces noisy, unparseable output.

Testing. Because it is a normal Monolog channel, Log::spy() / Log::shouldReceive() in feature tests work unchanged. Prefer asserting on the log facade over asserting on captured STDOUT — the latter couples your tests to terminal formatting.

Honest evaluation before adopting: a plain Monolog stream handler pointed at php://stdout gets you 95% of this in three lines of config/logging.php with zero dependencies. Adopt this package when you want its formatting/config conventions and don't want to hand-maintain that handler; skip it if that's the only thing you'd use it for.

Gotchas and Tips

• Laravel 8 is gone as of v0.1.4. This is the headline of the release: L8 support removed, dependency constraints fixed. Upgrading on an L9+ app should be uneventful, but run composer update archtechx/console-log -W and check the resolved Laravel/Monolog versions — the "fix dependencies" change may tighten constraints in ways that conflict with a pinned Monolog major.
• It is 0.x. No semver BC guarantee. Pin it ("^0.1.4" at minimum, exact pins if you're conservative) and actually read the changelog on update. A 0.1.x bump removed a supported Laravel major version entirely, which tells you how the maintainers treat minor numbers.
• Log volume in containers. STDOUT has no rotation. Your log driver/aggregator must handle retention. A chatty console channel behind a daily rotation mindset is a fast way to a five-figure CloudWatch bill.
• Secret leakage. Console output frequently ends up in CI job logs and shared terminal sessions, which are far more widely readable than storage/logs. Audit what your context arrays carry before flipping LOG_CHANNEL=console in CI.
• Buffering. Under Supervisor or a pipe, output can be block-buffered; you may see nothing until the process exits. Check PHP's output_buffering and the aggregator's flush behaviour before diagnosing this as a package bug.
• config:cache will bite you. Changing LOG_CHANNEL in .env has no effect until php artisan config:clear && php artisan config:cache. This is the single most common "the package doesn't work" report.
• Channel name resolution. If the package registers its own channel, a same-named entry in config/logging.php from a previous package will shadow it. Log::channel('console') throws a clear InvalidArgumentException for unknown channels — read that message before assuming a registration problem.
• Extension points. The driver ultimately resolves a Monolog handler and formatter, so customising output means overriding the formatter in the published config rather than editing the package. Avoid forking for cosmetic changes; a custom Monolog formatter class in your own app does the job.

Verdict on v0.1.4: worth updating if you're on Laravel 9+ and have no conflicting Monolog pins — it's a dependency hygiene release. Do not update if you're on Laravel 8; stay on 0.1.3 until you've upgraded the framework.