Getting Started

Reality check first: orukusaki/slackbundle is a Symfony2 bundle, not a Laravel package. There is no SlackServiceProvider, no facade alias, and no config/slack.php. Everything in it is built around Symfony's DI container, AppKernel::registerBundles(), and the slack: configuration tree — none of which exist in Laravel. You will not be able to composer require it and start calling Slack::send().

That said, the useful part of the package is the thin client wrapper and the configuration shape it teaches. Here's how to actually get value from it in a Laravel codebase.

Read the source before installing. The bundle is small. Look at, in order:
- README.md — usage example (usually 5–10 lines, that's the whole API surface)
- DependencyInjection/Configuration.php — the real config schema (token, webhook URL, default channel, username, icon)
- Resources/config/services.xml — the service ID and class you'd be injecting
- SlackBundle.php — usually empty in bundles this size
Decide on the underlying client. Most Symfony2 Slack bundles of this vintage wrap maknz/slack (incoming webhook client) or hand-roll a Guzzle call to https://hooks.slack.com/services/.... In Laravel you should install that underlying library directly:
```
composer require maknz/slack
```
(It is archived but stable and tiny; the alternative is laravel/slack-notification-channel, which is the modern, first-party answer.)
Check PHP compatibility. Anything tagged as a Symfony2 bundle is likely pinned to php: >=5.5 / symfony/symfony: ~2.3|~2.7. On a modern Laravel (PHP 8.2+) Composer will refuse or you'll get deprecation spam.

First use case worth doing today: a deploy/alert notification.

// config/services.php
'slack' => [
    'webhook' => env('SLACK_WEBHOOK_URL'),
    'channel' => env('SLACK_CHANNEL', '#general'),
    'username' => env('SLACK_USERNAME', 'Laravel'),
],

// app/Support/SlackNotifier.php
class SlackNotifier
{
    public function send(string $text, ?string $channel = null): void
    {
        (new \Maknz\Slack\Client(config('services.slack.webhook')))
            ->to($channel ?? config('services.slack.channel'))
            ->from(config('services.slack.username'))
            ->send($text);
    }
}

If you are genuinely on a Symfony2 app (rare but possible), then: composer require orukusaki/slackbundle, add it to registerBundles(), add a slack: block to config.yml, and inject the slack service. That's the entire onboarding.

Implementation Patterns

Bind it as a singleton, not a helper. If you choose to reuse the bundle's client class directly (vendoring the one class is often easier than fighting its Symfony wiring), wrap it in a service provider so you have one place to swap implementations:

// app/Providers/SlackServiceProvider.php
public function register(): void
{
    $this->app->singleton(SlackNotifier::class, fn () =>
        new SlackNotifier(config('services.slack.webhook'))
    );
}

Environment-based channel routing. This is where a Slack integration earns its keep. Don't hardcode #general:

'channel' => match (app()->environment()) {
    'production' => '#ops-alerts',
    'staging'    => '#staging-builds',
    default      => '#dev-sandbox',
},

Exception handler hook. The classic day-to-day use — mirror logged errors into a channel. Keep it throttled (see Gotchas) so a loop of 500s doesn't spam 400 messages:

public function report(Throwable $e): void
{
    parent::report($e);

    if ($this->shouldReport($e) && app()->isProduction()) {
        rescue(fn () => app(SlackNotifier::class)->send(
            ":rotating_light: `".get_class($e)."` — ".Str::limit($e->getMessage(), 200)
        ));
    }
}

Queue it. HTTP-to-Slack inside a request is a latency and failure vector. A tiny job keeps the request path clean and gives you retries:

class NotifySlack implements ShouldQueue
{
    public int $tries = 3;
    public function backoff(): array { return [5, 15, 60]; }

    public function __construct(public string $text, public ?string $channel = null) {}

    public function handle(SlackNotifier $slack): void
    {
        $slack->send($this->text, $this->channel);
    }
}

Per-domain notifier methods. Rather than passing raw strings from controllers, expose intent:

public function orderFailed(Order $order): void
{
    $this->send(sprintf(
        ":x: Order #%d failed for *%s* (<%s|view>)",
        $order->id, $order->customer->name, url("/admin/orders/{$order->id}")
    ), '#commerce');
}

This is the pattern that pays off — the bundle's own API (a webhook POST with text, channel, username, icon_emoji, attachments) is thin enough that a 40-line wrapper around it gives you everything the bundle offered anyway.

If you truly need the Symfony bundle (you have a legacy Symfony2 sidecar or want the bundle's service in a Laravel-adjacent app): you'd have to bootstrap the Symfony DI container, register the bundle, and pull $container->get('slack'). In practice this means more code than reimplementing the call.

Gotchas and Tips

The biggest gotcha is the packaging: Symfony2 reached end-of-life in 2018. Symfony 2 bundles don't use composer extra.laravel, don't register auto-discovery, and their dependency constraints will usually block installation on modern PHP. Expect to either fork the single client class or copy it.
Webhook vs. Token. Two different Slack APIs get conflated constantly. An incoming webhook is a URL you POST to; it cannot read messages, list channels, or resolve user IDs. A bot/user token hits slack.com/api/* and can do everything. This bundle almost certainly wraps the webhook path (that's what was popular in the Symfony2 era). If you need to read or look up, you need a different tool.
Slack returns HTTP 200 on failures. A 200 from hooks.slack.com with body invalid_payload or channel_not_found is a failure. Always inspect the response body, not just isSuccessful. The underlying clients mostly hide this — wrap it yourself if it matters.
Channel naming. Public channels take #name; DMs take @username; private groups cannot be addressed by name — you must use the channel ID (C0…/G0…) obtained from the API. This trips people up when they move from a public alerting channel to a private one.
Rate limits. Slack's webhook path is roughly 1 message/second per channel and will silently drop or 429 beyond that. In an exception handler this is a real footgun — throttle with RateLimiter::attempt():
```
RateLimiter::attempt('slack-alerts', 1, fn () => $notifier->send($text), 10);
```
Never send at boot. Don't call the client from a service provider's register() or boot(), from a global middleware, or from config:cache. It makes artisan commands (including queue:work and migrate) hang or fail when the network is down.
link_names and escaping. Slack does not auto-link @user or #channel inside a plain text payload unless link_names: true is set, and &, <, > must be HTML-escaped (&, <, >). If you're interpolating user-entered strings, escape them or Slack will mangle the message or drop it.
Test against a real webhook, in a real test channel. There is no official Slack sandbox. Create a private #bot-test channel, one webhook, and always point local/CI at it. Don't try to fake the HTTP call in a way that hides payload-shape bugs — that's exactly where Slack's API differs.
Extension points, if you keep the bundle: the service alias (slack) is the seam. Decorate or swap it in services.xml to replace the client without touching call sites. In Laravel, the equivalent seam is the container binding on SlackNotifier — bind an interface and you can swap webhook for API, or for a null logger in tests.
Treat this as a reference implementation, not a dependency. At 10 stars, no meaningful maintenance, and a Symfony2 target, you're one PHP upgrade away from it breaking. The concepts (config-driven webhook, a singleton client, channel-per-environment) transfer cleanly; the code probably won't. For Laravel, laravel/slack-notification-channel is the supported path and covers attachments, blocks, and queued notifications out of the box.

Slackbundle Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips