Socket Io Bundle Laravel Package

Getting Started

• Install with composer require tourze/socket-io-bundle. Note this is a Symfony bundle, not a Laravel package — there is no Laravel auto-discovery. You will either use it inside a Symfony service, or manually wire its core classes into a Laravel service provider.
• Look first at the bundle’s README, composer.json, Resources/config/services.*, and any Client/Connection classes. Those show what is actually provided (client vs. server-side helpers).
• First use case: emit a server-side event from Laravel to a running Socket.IO server (e.g. notify a connected browser). Start with a small Artisan command or queued job that instantiates the bundle’s client, connects to http://localhost:6001, and emits a test event. Confirm the event arrives in a browser console before wiring it into application events.
• Because the 0.3.0 release notes contain only an empty changelog link, treat 0.3.0 as unverified. Pin 0.3.0 explicitly and review the diff from 0.2.0 before upgrading production code.

Implementation Patterns

• Laravel service provider bridge: bind the bundle’s client/connection class as a singleton in a custom service provider. Inject configuration from config/socket_io.php (host, port, path, auth headers, timeout) instead of relying on Symfony’s container.
• Domain events → queued emit: listen to Laravel events (e.g. OrderShipped) and dispatch a queued job that performs the Socket.IO emit. This keeps HTTP requests fast and isolates connection failures from user-facing flows.
• Redis adapter for scale: if you run multiple Socket.IO nodes, configure the Socket.IO server with the Redis adapter and have Laravel either emit through the package or publish directly to Redis. Pick one path per event type to avoid duplicate broadcasts.
• Facade or helper: wrap the client in a small SocketIo facade or helper method so application code does not depend on bundle internals. This also gives you a single place to swap implementations later.
• Testing: bind a fake client in tests that records emitted events. Assert on the recorded payloads rather than opening real sockets in CI.
• Symfony-first integration: if your Laravel app already talks to a Symfony service, keep the bundle inside that service and expose a simple HTTP or queue interface to Laravel. Avoid pulling Symfony-specific container assumptions into Laravel’s container.

Gotchas and Tips

• No Laravel package discovery: the bundle will not register itself in Laravel. You must manually instantiate or bind its classes; Symfony-specific configuration and compiler passes will not run.
• Changelog is empty: 0.3.0’s release notes provide no detail. Check the GitHub compare view for namespace changes, constructor signature changes, or removed configuration keys before upgrading.
• Blocking calls in web requests: Socket.IO handshakes and emits can block. Always prefer queued jobs or short timeouts in request paths.
• Connection lifecycle: long-running queue workers can hold stale connections. Reconnect on failure and consider closing connections after each job unless the client explicitly supports persistent reconnects.
• Configuration quirks: Symfony bundle config (e.g. config/packages/socket_io.yaml) is not read by Laravel. Map the same values into Laravel config and pass them explicitly to the client.
• Extension points: look for injectable HTTP clients, event serializers, and connection factories. Those are the safest places to customise without forking the bundle.
• Debugging: enable verbose logging on both sides; set DEBUG=socket.io-client:* in the browser, check the server handshake path (/socket.io/), and verify CORS and auth headers. If events silently disappear, confirm the namespace and event name match exactly.
• Version pinning: until 0.3.0 is documented, pin the exact version ("tourze/socket-io-bundle": "0.3.0") and avoid floating constraints.