Product Decisions This Supports
- Deprecation and migration planning, not new feature development. ChatKit is shut down and the wrapper is archived; the only real product decision this supports is answering "what do we owe users still on ChatKit, and how fast do we get off it?"
- Vendor-risk triage across the dependency tree. Treat this as a template for auditing other single-vendor SDK wrappers: check the upstream provider's roadmap blog, the wrapper's release cadence, and whether the maintainer has archived the repo before you build a roadmap on it.
- Build vs. buy vs. wrap. The wrapper itself added little beyond the Chatkit PHP SDK (config, facade, service provider). It is a good cautionary example for the recurring question: does a thin Laravel wrapper earn its place in
composer.json, or should the team integrate the SDK directly so an upstream sunset doesn't leave you two removals deep?
- Scope and sequencing for a migration epic. If ChatKit powers in-app messaging, support chat, or notifications, this becomes a roadmap line item with user-facing impact (feature parity, message history export, notification channel changes) that competes with new work.
- Incident and support-readiness planning. If the shutdown has already landed, this drives decisions about degraded-mode messaging, support-macro updates, and status-page/communications commitments.
- Sourcing and procurement criteria. Supports writing a checklist for future real-time/chat vendors: contractual notice periods, data-export guarantees, and escape-hatch requirements before signing.
- Do not use this to scope net-new work. Any backlog item that assumes ChatKit as an available platform should be closed, re-scoped, or explicitly deferred pending a replacement decision.
When to Consider This Package
There is essentially one legitimate case: you already depend on it and need to understand what you're holding.
Consider it only when:
- It is already in a shipped
composer.json and you are doing inventory, dependency-risk scoring, or a security/licence audit.
- You need to plan the removal — mapping which of your app's classes, config keys, and events touch the wrapper before you swap providers.
- You are documenting a historical decision (why a past team chose ChatKit) for a post-mortem or architecture decision record.
Look elsewhere — decisively — when:
- Any greenfield or new-feature work. Archived, last released March 2020, upstream product shut down. There is no support path, no security patching, and no future compatibility with current Laravel or PHP versions. Composer constraints will likely block modern Laravel anyway.
- Anything user-facing or revenue-bearing. Betting a customer-visible channel on a discontinued vendor is a self-inflicted outage.
- You need ongoing vendor support, SLAs, or compliance attestations. None exist.
- You want a maintained Laravel-native chat/messaging layer. Evaluate actively maintained alternatives (Pusher Channels plus your own domain layer, Laravel Reverb/websockets for self-hosted real-time, or a current commercial chat vendor) — and evaluate the provider's health first, not just the wrapper's.
- Community support matters. 22 stars and an archived repo means no realistic path to an answer when something breaks.
How to Pitch It (Stakeholders)
To executives (one paragraph): This package is a thin Laravel adapter for ChatKit, a Pusher product that has been discontinued; the adapter itself was last released in March 2020 and the repository is archived. It is not a candidate for new investment. Its relevance is limited to confirming that any product capability still depending on it has a funded migration path and a communicated timeline. The strategic lesson is about vendor concentration: we should be able to name, for every third-party SDK in our stack, the provider's commitment horizon and our exit plan — and we currently cannot.
To engineering leadership: Treat this as a known-end-of-life dependency, not a library choice. Recommended posture: inventory where it is used, freeze new usage, pick a replacement at the platform level (not the wrapper level), and integrate the successor SDK directly rather than adopting another single-maintainer wrapper. Budget the migration as real work — message-history export, notification path changes, and any user-visible behaviour differences — and add a dependency-health check (archived status, upstream roadmap, release recency, maintainer count) to the intake process so the next one is caught before it reaches production.
To the delivery team: No new tickets should reference ChatKit. Existing tickets that do should be relabelled as migration work, and the wrapper should be removed from composer.json as part of the replacement rather than patched in place. Anything customer-facing that depends on it needs a named owner and a date.