Logger Laravel Package

Getting Started

v2.6.4 is an additive release: it introduces basic Slack notification support. No breaking changes or deprecations are listed, so existing integrations should continue to work after a normal composer update.

Start by checking:

1. The package README section on Slack notifications — this is the source of truth for the exact channel class, config keys, and supported transport (webhook vs. bot token).
2. The published config file (config/<package>.php) for new Slack-related keys.
3. The changelog/service provider to see whether the feature is opt-in or enabled by default.

Minimal setup:

composer update <vendor>/<package>
php artisan vendor:publish --provider="<Vendor>\\<Package>\\<PackageServiceProvider>" --tag=config
php artisan config:clear

Add the required Slack credentials to .env — typically a webhook URL or bot token, plus a default channel:

SLACK_WEBHOOK_URL=https://hooks.slack.com/services/...
SLACK_CHANNEL=#deployments

Verify end-to-end before wiring it into application events:

php artisan tinker

app(<PackageSlackNotifier>::class)->send('Test from staging');

The first practical use case is low-risk operational signalling: deploy notifications, failed scheduled jobs, or exception summaries to an internal channel. Treat it as a “basic” transport and confirm the capabilities in the README before relying on it for anything with formatting or delivery guarantees.

Implementation Patterns

Wrap it behind an application-level notifier. Don’t call the package’s Slack API directly from controllers or models. Introduce a small service or dedicated Laravel notification classes so the package remains an implementation detail:

final class SlackAlert
{
    public function __construct(private PackageSlackNotifier $slack) {}

    public function deploymentFailed(Deployment $deployment): void
    {
        $this->slack->send(sprintf(
            'Deployment %s failed for %s',
            $deployment->id,
            $deployment->environment
        ));
    }
}

Drive it from events and listeners. Keeps business flow decoupled and makes it easy to disable notifications in tests or local environments:

Event::listen(DeploymentFailed::class, function (DeploymentFailed $event) {
    app(SlackAlert::class)->deploymentFailed($event->deployment);
});

Queue notifications. Slack is an external HTTP dependency; never let it sit in the request path. If the package exposes a Laravel notification channel, implement ShouldQueue and use afterCommit() so you don’t announce something that was rolled back:

final class DeploymentFailedNotification extends Notification implements ShouldQueue
{
    use Queueable;

    public function __construct(public Deployment $deployment)
    {
        $this->afterCommit();
    }

    public function via(object $notifiable): array
    {
        return ['slack'];
    }
}

Separate channels by environment. Route staging and production to different Slack channels, and disable entirely in local/testing. Prefer config-driven routing over hardcoded channel names:

'slack' => [
    'webhook' => env('SLACK_WEBHOOK_URL'),
    'channel' => env('SLACK_CHANNEL', '#general'),
    'enabled' => env('SLACK_NOTIFICATIONS_ENABLED', false),
],

Test with fakes, not real HTTP. Use Notification::fake() or Http::fake() depending on how the package sends. Assert that the notification was dispatched and, where possible, assert the channel and payload shape:

Notification::fake();

$this->post('/deployments/fail', $payload);

Notification::assertSentOnDemand(DeploymentFailedNotification::class);

Use it for scheduled-task and health-check visibility. A scheduled command that reports failures to Slack is one of the highest-value, lowest-effort integrations:

$schedule->command('reports:generate')
    ->daily()
    ->onFailure(fn () => app(SlackAlert::class)->jobFailed('reports:generate'));

Gotchas and Tips

• “Basic” is the key word. The release adds basic Slack functionality, not a full Slack SDK. Assume limited support for Block Kit, threads, message updates, retries, and multi-workspace routing until the README says otherwise. Don’t design critical alerting around unverified features.
• Webhook URLs are secrets. Keep them in .env/secret storage, exclude them from logs, and never echo the full URL in exception messages. A leaked webhook allows anyone to post to your channel.
• Config caching bites. After changing Slack env vars, run php artisan config:clear (or config:cache in deploy). A stale config cache is the most common reason “the notification silently doesn’t send.”
• Restart queue workers after deploy. Queued notifications use the worker’s bootstrapped config and code. php artisan queue:restart should be part of your deployment pipeline.
• Respect Slack rate limits. Slack limits posting per channel; bursts can return 429s. Queue and stagger notifications, and implement backoff if the package doesn’t. Batch noisy events into a digest rather than one message per item.
• Don’t let notification failures break business logic. Wrap sends in try/catch, log failures, and implement failed() on queued notifications. A Slack outage should never fail a deployment, payment, or job.
• Use afterCommit() for anything transaction-adjacent. Otherwise you may announce records that were rolled back.
• Check config publish behaviour before upgrading. If v2.6.4 adds new config keys, compare the package’s config with your published copy rather than blindly running vendor:publish --force, which will overwrite customisations.
• Extension point: if basic Slack support is too limited, keep the package for other functionality and implement a custom Laravel notification channel or a small Slack client behind your own interface. That keeps a future swap cheap.
• Verify with a real send in a non-production channel before enabling in production — unit tests with fakes won’t catch a malformed webhook, missing bot scope, or wrong channel name.