Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Php Messenger Laravel Package

codedungeon/php-messenger

A lightweight PHP messenger for dispatching messages to handlers through a configurable bus, with middleware pipelines, typed message handling, and optional Laravel integration—a simple, framework-agnostic foundation for commands, queries, and events.

View on GitHub
Deep Wiki
Context7

Getting Started

Install

composer require codedungeon/php-messenger

There is no service provider and no config file to publish — this is a standalone, framework-agnostic console helper, so it works in plain PHP scripts, Composer scripts, and Laravel/Symfony commands alike. In a Laravel app, add it under require-dev if you only use it in seeders, deploy scripts, or custom Artisan commands that don't ship to production.

Where to look first

  1. README.md — the primary documentation; the API surface is intentionally small.
  2. src/ — normally a single Messenger class; confirm the exact namespace (Codedungeon\PHPMessenger\...) before importing.
  3. tests/ — the most reliable specification of method names and output format. With a package this small and this lightly used (2 stars, 0 dependents), treat the test suite as the authoritative API reference rather than guessing method names from memory.

First use case

Replace ad-hoc echo / fwrite(STDERR, ...) calls in a custom Artisan command with typed status lines:

use Codedungeon\PHPMessenger\Messenger;

class SyncProducts extends Command
{
    protected $signature = 'products:sync';

    public function handle()
    {
        Messenger::info('Starting product sync...');
        // ... work ...
        Messenger::success('Synced 1,248 products');
        Messenger::warning('12 products skipped (missing SKU)');

        return self::SUCCESS;
    }
}

That's the entire day-one value proposition: consistent, colorized, greppable status output in one line instead of hand-rolled ANSI escapes.

Implementation Patterns

Wrap it, don't sprinkle it. Static calls are convenient but untestable and hard to swap. Bind a thin interface in the container and delegate:

interface ConsoleReporter
{
    public function info(string $msg): void;
    public function success(string $msg): void;
    public function warn(string $msg): void;
    public function error(string $msg): void;
}

class MessengerReporter implements ConsoleReporter
{
    public function info(string $msg): void    { Messenger::info($msg); }
    public function success(string $msg): void { Messenger::success($msg); }
    public function warn(string $msg): void    { Messenger::warning($msg); }
    public function error(string $msg): void   { Messenger::error($msg); }
}

Now commands and services depend on ConsoleReporter, and tests get a no-op or array-collecting fake instead of writing to stdout.

Step-based reporting for long-running commands. Pair status lines with a step counter so failures are localizable in logs:

foreach ($batches as $i => $batch) {
    Messenger::info(sprintf('[%d/%d] Processing batch %s', $i + 1, $batches->count(), $batch->id));
    try {
        $batch->process();
        Messenger::success("  batch {$batch->id} ok");
    } catch (Throwable $e) {
        Messenger::error("  batch {$batch->id} failed: {$e->getMessage()}");
        $failures++;
    }
}

Gate verbose/debug output. The package exposes verbosity/quiet toggles (check the tests for the exact setters). Wrap them behind your own --verbose flag rather than letting every caller flip global state:

if ($this->option('verbose')) {
    Messenger::debug($payload);   // only noisy in verbose runs
}

Use it in non-Laravel contexts too — standalone deploy scripts, composer.json script handlers, database seeders, and one-off maintenance scripts. Because it has no framework dependencies, the same output style carries across all of them.

Don't mix formatting paradigms in one command. Inside an Artisan command you have two options: $this->components->info(...) / $this->line(...) (which respect --quiet, --no-ansi, and output redirection automatically) or Messenger. Pick one per command. Interleaving them produces inconsistent indentation and inconsistent quiet-mode behavior.

Gotchas and Tips

Vendor risk is the headline. Two stars, zero dependents, a single maintainer. It is a pure-output sugar library, so the blast radius of abandonment is small — but pin the version ("codedungeon/php-messenger": "^1.0") and be prepared to vendor the class into app/Support/ if it stalls. Budget five minutes to read all of src/ so you could replace it.

ANSI escapes leak into redirected output. Piping a command to a file or into a log aggregator bakes raw \033[32m sequences into the artifact. Guard it:

$useColor = stream_isatty(STDOUT) && ! getenv('NO_COLOR') && ! $this->option('no-ansi');

If the package doesn't expose a "plain" mode, add one in your wrapper.

Static state persists across tests. Any quiet/verbose flag set in one test bleeds into the next within the same PHPUnit process. Reset in tearDown(), or better, only ever mutate it through your wrapper so you have one place to reset.

Asserting output is awkward. PHPUnit's expectOutputString() compares the formatted string including color codes. Assert on your ConsoleReporter fake's collected messages instead of on real stdout — another reason to wrap.

Windows / PowerShell. Older cmd.exe and some CI runners don't interpret ANSI codes; output shows literal [32m. Detect the terminal or force plain output in CI (NO_COLOR=1 is the widely honored convention).

Verify the API before committing to it. The exact method names (info, success, warning, error, debug, important, notice) and whether they're static, fluent, or instance-based vary between versions of small packages like this. Grep the tests; don't trust autocomplete from a stale memory of the README.

Extension point: your wrapper, not the class. There's no event system, no formatter interface to implement. If you need structured JSON logs, timestamps, or PSR-3 bridging, that logic belongs in MessengerReporter — subclassing the vendor class couples you to its internals for no gain.

Consider the mature alternative. For new code, symfony/console's SymfonyStyle (available in every Laravel app already) gives you $io->success(), $io->warning(), $io->error(), automatic -q/--no-ansi handling, and a decade of maintenance. Reach for php-messenger when you want the zero-dependency, drop-in one-liner in a script that isn't already bootstrapping a console application — that's precisely the niche it fills.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
ippanelcom/laravel-sdk
adachsoft/changelog-linter
adachsoft/collection
payerurl/telegrambot-crypto-payment-instant-payout
dskripchenko/laravel-hybrid-search
riorizkyrainey/lara-ced
mehedimi/static-vel
zharp/zharp
nonsapiens/bigquery-model-sync
lgu-bayambang-ict-office/lgu-laravel-development-standards
andydefer/laravel-support
se7enxweb/flysystem
lampwick/laravel
jeslage/statamic-emojis
micahdshackelford/rmap-laravel
draftsmaninc/draftsman
square-bit/laravel-volition
himito/laravel-mailman
htinlynn/genius-helper
maco-studios/hephaestus