Wsclient Bundle Laravel Package

Product Decisions This Supports

• Real-time feature feasibility (push consumption in PHP): Informs the roadmap question "can our Symfony backend subscribe to an external WebSocket feed?" — e.g. consuming live pricing, trading, chat, or notification streams from a third-party provider rather than polling. This bundle is a reference point for that capability, not a shipping choice.
• Build vs. buy vs. borrow for real-time plumbing: Helps frame the decision between (a) writing an in-house WebSocket client layer, (b) adopting a maintained library (Ratchet/Pawl, ReactPHP, Swoole/RoadRunner), or (c) buying a managed relay (Mercure, Pusher, Ably). The existence of a small, archived bundle like this is evidence that the "borrow" option in this niche has a thin, stale supply.
• Architecture scope: Supports the call on whether PHP should be a WebSocket client at all, versus delegating stream consumption to a sidecar/worker service in a language with mature async I/O, and keeping Symfony as the consumer of an internal queue or HTTP webhook.
• Interface stability as an adoption gate: The latest patch (v5.4.1) exists only to restore methods on ResponseAdapterInterface that the previous release removed — i.e. a backwards-incompatible change shipped without a major version bump, then walked back. For roadmap purposes this is a concrete data point that this package cannot be relied on for stable public contracts, which is the minimum bar for anything we'd wrap or extend.
• Legacy/portfolio audit: If this appears in a dependency tree, it triggers a maintenance-risk and upgrade-path decision (Symfony 2/3-era code, 2015-era release cadence, no security response). The v5.4.1 churn adds an "unknown-blast-radius" question to any upgrade: which interfaces moved between which point releases.
• Vendor/integration diligence: Useful as a checklist item when a partner's SDK docs reference this bundle — a signal that the integration guidance is dated and the partner's PHP story may need re-validation.
• Not a differentiator: Low stars (1), zero dependents, and archived status mean this cannot be positioned as a competitive or accelerated-time-to-market lever in any roadmap narrative.

When to Consider This Package

Adopt only under narrow, explicitly time-boxed conditions:

• Reference reading, not dependency: You want a compact example of how a Symfony bundle wires a WebSocket client into the service container (DI configuration, connection lifecycle, event hooks) before specifying your own implementation.
• Frozen legacy system: An existing service already depends on it, is in maintenance-only mode, and rewriting the transport layer is out of scope for the current quarter. Even then, isolate it, pin the exact version, and plan an exit.
• Prototype with zero production exposure: A throwaway spike to prove a data feed is reachable, with a hard rule that it never reaches a released artifact.

Look elsewhere when any of the following is true — which, for most teams, is all of them:

• You need production support. The package is archived, has 1 star and 0 dependents, and its releases stopped in the Symfony 2/3 era. There is no maintainer, no CVE response path, and no compatibility work for modern PHP or Symfony (6/7). That is a standing security and upgrade liability.
• You need stable public contracts. The v5.4.1 patch is a retrocompatibility repair for ResponseAdapterInterface methods dropped in the preceding release. Interfaces are being changed across patch versions, so anything you build against them — adapters, decorators, test doubles — can break on a routine composer update.
• Your runtime is current. Modern PHP async options (Pawl, ReactPHP, AMPHP, Swoole, RoadRunner, FrankenPHP worker mode) or a managed service (Mercure, Pusher, Ably, Kafka/Redis streams) deliver the same outcome with active maintenance.
• You need reconnection/backoff, auth refresh, heartbeats, or observability. Assume none of this is production-grade or documented to current standards; budget to build it.
• Dependency policy forbids abandoned code. Archived + zero dependents fails virtually any sane supply-chain gate, and a BC-break-then-revert in a patch release is exactly the pattern those gates are meant to catch.
• You are choosing a strategic real-time platform. Pick a direction with a maintainer and a roadmap; this is not a platform decision you can build on.

How to Pitch It (Stakeholders)

One line: A 2015-era Symfony bundle for consuming WebSocket feeds from PHP — useful as a design reference, disqualified as a dependency.

For executives: We re-evaluated m6web/wsclient-bundle following its v5.4.1 release. It is MIT-licensed and conceptually on-target, but it is archived, essentially unmaintained, has one star and zero downstream dependents, and has no compatibility work for modern Symfony. The new release does not change that verdict — it is a bug-fix that restores methods on ResponseAdapterInterface that the previous release removed, meaning the project is still shipping backwards-incompatible interface changes in point releases. Recommendation: do not adopt. If real-time ingestion is on the roadmap, we should choose a maintained library or a managed relay and treat the bundle only as a pattern reference. Cost of the decision is near zero now; cost of reversing an adoption later is a rewrite plus a security review.

For engineering: Read it for the bundle/DI structure if helpful; do not add it to composer.json. Treat the v5.4.1 notes as a warning rather than reassurance: ResponseAdapterInterface gained and lost public methods between patch versions, so any wrapper, adapter, or mock written against it is a recurring upgrade hazard. Target Pawl/ReactPHP or a managed service for the client side, and keep the transport behind an interface you own so the choice stays reversible. If anyone finds it already in a tree, pin the version, flag it as tech debt with an owner and a replacement date, and check whether local code implements or extends ResponseAdapterInterface — those call sites are the ones most likely to break on the next bump.

Decision requested: Confirm real-time ingestion is (or is not) on the roadmap, and if it is, approve a short spike comparing a maintained PHP client against a managed relay — with this package explicitly excluded from both options.