Laravel Bearychat Laravel Package

Getting Started

1. Confirm viability before installing. This package is archived and was built for the Laravel 5.x era. Run composer require elfsundae/laravel-bearychat on a throwaway branch and check the solver output — if it fights your laravel/framework or guzzlehttp/guzzle constraint, stop there and treat the package as a reference implementation rather than a dependency.

2. Install and let discovery do its job. On Laravel 5.5+ the service provider is auto-discovered. On older apps, register the provider in config/app.php (check the package's composer.json extra.laravel.providers for the exact FQCN — namespaces in this package follow ElfSundae\BearyChat\...).

3. Publish and configure.

   php artisan vendor:publish --provider="ElfSundae\BearyChat\BearyChatServiceProvider"
   

   Then put the robot/incoming-webhook URL in .env:

   BEARYCHAT_WEBHOOK=https://hook.bearychat.com/=bw/xxxxxxxx
   

   and reference it from the published config (or config/services.php if that's where the package reads from — the README is the source of truth here).

4. First use case: deploy/CI notification. The highest-value, lowest-risk integration is a one-way "push a message to a channel" from a listener or console command. Start there before wiring it into user-facing notifications.

// app/Listeners/NotifyDeployFinished.php
public function handle(DeployFinished $event)
{
    BearyChat::to(config('bearychat.channel'))
        ->text("Deploy {$event->tag} finished on {$event->env}");
}

5. Where to look first in the repo: the service provider (what's bound in the container), the message/payload builder (what fields it actually serializes), and the notification channel class if present. Those three files tell you everything the package does.

Implementation Patterns

Notification channel (the idiomatic path). If the package ships a notification channel, prefer it over the facade — you get queueing, Notification::fake(), and per-notifiable routing for free.

use Illuminate\Notifications\Notification;

class InvoicePaid extends Notification
{
    public function via($notifiable)
    {
        return ['bearychat'];
    }

    public function toBearyChat($notifiable)
    {
        return (new BearyChatMessage)
            ->text("Invoice #{$this->invoice->id} paid")
            ->markdown("**Invoice #{$this->invoice->id}** paid — ¥{$this->invoice->amount}");
    }
}

On-demand routing for models that have no stored webhook:

Notification::route('bearychat', config('bearychat.webhook'))
    ->notify(new InvoicePaid($invoice));

Or implement routeNotificationForBearyChat() on the notifiable to resolve the webhook/channel per-tenant.

Multiple destinations. Keep one config entry per team/channel (bearychat.webhooks.ops, .alerts, .billing) and select at call time. Don't scatter raw URLs through the codebase — you will rotate them.

Queue everything. Implement ShouldQueue on the notification and use ->afterCommit() (Laravel 8+) or dispatch from an Event::listen after the transaction. A webhook call inside a DB transaction is a classic way to notify people about work that then rolls back.

Direct facade for non-notifiable events — cron jobs, queue failures, Artisan::starting. Wrap it in a small BearyChatNotifier service class of your own so the rest of your app doesn't import the package namespace; that one wrapper is what makes the eventual migration cheap.

Testing.

Notification::fake();
// ...
Notification::assertSentOnDemand(InvoicePaid::class);

For the facade path, point the config at a local stub and assert on the recorded request, or swap the underlying HTTP client with Http::fake() if the package uses the Laravel HTTP client (it likely uses Guzzle directly, in which case inject a mock handler).

Integration tips. Hook it into Horizon::routeMailNotificationsTo-style monitoring equivalents, Queue::failing(), and scheduled-task ->onFailure(). Those are the places where a chat ping actually earns its keep.

Gotchas and Tips

• Archived means frozen. No security patches, no Laravel 9/10/11 compatibility work, no Guzzle 7 fixes. Pin the version, run composer audit, and budget for replacement. A 0.35 health score and 73 stars is a signal, not a verdict — but treat the dependency as technical debt from day one.
• Verify BearyChat itself is still reachable. Before you build on the webhook API, confirm the service and your workspace's robots are functioning. If the upstream product has changed or sunset, the whole integration is moot and you should port to a generic webhook notifier (Slack, DingTalk, Feishu, or a plain Http::post($url, $payload)).
• Webhook URLs are secrets. Anyone with the URL can post to the channel. Keep it in .env, exclude it from logs and exception reporters, and rotate on any leak. Never put a default URL in a committed config file.
• Payload shape drift. text vs markdown render differently, and attachment/field schemas are easy to get subtly wrong. Test the exact payload against a real channel in a sandbox before shipping — a 200 response does not mean it rendered.
• Failures are silent. Webhook calls are fire-and-forget by nature. Wrap the send in a try/catch and log failures; otherwise a rotated webhook URL means notifications quietly stop and nobody notices for a week. Consider a dead-man's-switch ping alongside production alerts.
• Timeout and retry defaults. Set an explicit HTTP timeout (2–5s) so a slow BearyChat endpoint can't stall your queue workers. Retry at most once or twice — a notification is not worth blocking a job.
• Version pinning. If the package pulls an old Guzzle, you may have to isolate it or use replace/conflict rules. Check composer why guzzlehttp/guzzle after install.
• Extension points. If you need behavior the package doesn't expose (retries, custom payload fields, per-tenant routing), don't fork it — write a thin BearyChatNotifier wrapper around it, or drop to a plain HTTP client. The package's value is the config/notification plumbing, and that's a couple dozen lines to reimplement.
• Migration path. Because everything routes through your own notifier class, swapping the archived package for laravel/slack-notification-channel or a 20-line Http::post webhook should be a one-file change. Design for that from the start, and you'll have gotten the day-to-day value without the long-term risk.