Slack Client Laravel Package

Product Decisions This Supports

• Build vs. buy for the notification layer. The package reduces "send a Slack message" to a single Slack::sendMessage() call, which makes the entry cost look like one Composer line. The decision that actually matters is the exit cost: the package's last release was October 2018, it has 51 stars and zero dependents, and its RTM differentiator is a protocol Slack has retired for new apps. Budget for the replacement path, not just the install.
• Roadmap gating on real-time vs. outbound-only messaging. RTM is the package's sole differentiator, and Slack no longer grants RTM to newly created apps. That directly determines whether the product can promise live bot conversations and chat-driven workflows, or should commit only to fire-and-forget outbound notifications. Make this call before it lands in a spec.
• Scope triage for internal tooling. The realistic use case is internal, low-volume, low-stakes messaging — deploy alerts, incident pings, admin notifications, review requests. The recurring PM question applies: is this a feature worth a dependency, or a ~20-line Guzzle call we own outright?
• Strangler-fig sequencing for existing installs. If the package is already in the tree, the decision isn't "adopt or not" but "isolate and replace, in what order." The PM owns that sequencing: outbound messaging first (trivial to swap behind an interface), inbound bot logic last (the hard piece). Sequencing determines whether the migration ships or stalls behind its worst component.
• Feature-scoping guardrails on interactivity. This package sends messages, not responses to slash commands or interactive components. If a spec says "an Approve button in Slack," the answer is "Slack calls our webhook via the Events API," which this package does not provide. Catch that mismatch at spec review, not at implementation.
• A reusable dependency-governance signal. 51 stars, zero dependents, no vendor, six-year-old release, 2018-era transitive pins (Guzzle 6, old PSR/WebSocket libs). That's a template for a standing health gate — age, maintenance signal, blast radius, replacement path — instead of re-litigating every small MIT library proposal.
• Explicitly out of scope: customer-facing Slack integrations, compliance- or audit-relevant messaging, and any high-availability or high-throughput bot traffic. Those need a supported SDK with owned retry, rate-limit handling, and observability. Treat this package as unsuitable there, not merely "risky."

When to Consider This Package

Consider it only as a reference implementation or a legacy-maintenance target, and only when all of the following hold:

• Internal-only and non-critical. Notifications and occasional bot replies where a silent drop is annoying, not revenue-impacting.
• Low volume. No throughput, latency, or availability commitments ride on it.
• Laravel/PHP-native team, with a host app already pinned to PHP 7.x / Laravel ≤8, so the 2018-era dependency graph doesn't collide with the main application. Run composer why-not before assuming a clean drop-in.
• An existing Slack app already grandfathered into RTM. New Slack apps cannot use RTM, so a greenfield RTM build is off the table regardless of library quality.
• You are already committed to owning it. Any fix — a PHP 8 deprecation, a Slack response-shape change, a token-rotation 401, a WebSocket silent drop — is yours to author. No vendor, no maintainer, negligible community surface.
• A migration budget exists, and the interface is extracted from day one. One SlackMessenger interface with one implementation keeps the eventual swap to laravel/slack-notification-channel an afternoon rather than a sprint.

Look elsewhere if any of the following is true:

• Any customer-facing or revenue-adjacent surface. Use laravel/slack-notification-channel or a directly owned HTTP client.
• You need inbound interactivity — buttons, modals, slash commands, Events API callbacks. This package provides none of that; you need an HTTP endpoint Slack can call.
• The workspace enforces token rotation or modern granular scopes. The package assumes a legacy xoxb- bot-user token; restricted-scope tokens fail with cryptic not_allowed_token_type / missing_scope errors.
• You need delivery guarantees, rate-limit-aware retries, or observability. Slack returns 429 with Retry-After; the package's backoff behavior is unverified in the current era, and it surfaces very little on failure.
• You need a greenfield real-time bot. RTM is a dead end for new apps. Go to slack-php/slack-bolt (Socket Mode or Events API) instead.
• The host app is on Laravel 9+/PHP 8 and you can't isolate the package in its own service. Expect Composer conflicts.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, MIT-licensed PHP library that posts messages to Slack from our Laravel app with almost no code. It's fine for internal, low-stakes alerts — deploy notices, incident pings, admin notifications — and it's cheap to try. But it has been unmaintained since October 2018, has effectively no community, and its headline feature (real-time bot messaging) relies on a Slack protocol that is closed to new apps. So we treat it as a short-term internal convenience with a planned exit, not as infrastructure. The recommendation is to adopt it only behind our own thin interface, so replacing it later is a contained change rather than a refactor.

For engineering (the ask): Wire it up, but do not let Slack:: calls leak across jobs, listeners, and controllers. Extract a SlackMessenger interface with a single implementation class on day one; that single habit is what makes the eventual swap to laravel/slack-notification-channel or a ~20-line Guzzle client an afternoon instead of a sprint. Queue every send — a Slack call is an HTTP round trip and must never block a request. Cache getChannelId/getUserId lookups with Cache::rememberForever (IDs are stable). Read the token from config('slack.token') at call time to survive rotation. Escape user-derived content so a stray <!channel> can't ping the whole workspace. And if we're maintaining an RTM bot, add our own liveness probe — the package gives us no application-level heartbeat, and silent WebSocket half-opens are the classic failure mode.

The honest framing for both: this package is a bridge, not a destination. The measurable win is a few hours saved today; the measurable cost is a dependency we now own. Approve it for internal notifications with a named owner and a written replacement path — decline it for anything customer-facing or anything that needs interactive components.