Incompatibility with socket.io-emitter about socket.io-redis-adapter HOT 7 CLOSED

The only way at the moment is to stick with 0.1.3 version, and in options provide just host and port, to let use socket.io-redis his own redis package (which is same as socket.io-emitter). Its the way i get it working for now..

from socket.io-redis-adapter.

Yes, python implementation encountered no compatibility problems. 0.1.4-> 0.2.0 also modified ms format.

The day before yesterday to achieve a socket.io-python-emitter compatible modifying 0.2.0, awaiting merged into the trunk. GameXG/socket.io-python-emitter@2ece80a

Why not do a more curious over it? 0.2.0 channel name prefix plus mark, while receiving the old version of the channel name, and slowly transition it?

from socket.io-redis-adapter.

It's compatible after that commit: socketio/socket.io-redis-emitter@e656600 tested it today, and it works. Though that they will not fix that, cause last commit was a year ago.. So the issue is resolved at the moment.

from socket.io-redis-adapter.

@aPoCoMiLogin - fwiw, this was fixed here: socketio/socket.io-redis-emitter#27 and released as socket.io-emitter 0.3.0. your issue is even more apropos since socket.io-redis 0.2.0 was released to npm with this issue, though.

our company (like the unit tests) actually missed this original break in socket.io-emitter after socket.io-redis bumped to 0.2.0, so we had a production issue (WHOOPS).

unsure the best way to ensure this doesn't happen in the future on "peer"-related modules/repos in general, but I'm sure @rauchg and @nkzawa would be curious if you have a suggestion. (unless they already have a "fix" for this type of failure.)

my thoughts: maybe all of these inter-related packages should run their unit tests on the latest versions of each of their dependencies in package.json after any version in the socket.io family is bumped (at least majorly, if not minorly)...but that sounds really onerous, and probably involves some odd dynamic post-processing of the package.json file, and I don't even know if Travis/whatever would support that anyway?

either way: in this one particular case, instead of more testing, perhaps the construction of the base#namespace#room message pattern should just be centralized in socket.io-adapter (if I understand the vision & module relationships properly?), or some other independent dependency. ultimately it feels like protocol/API specifications like this should not be copy-pasted/hard-coded in three (or more?) modules - it's very risky (obviously, since it blew up here), AND makes synchronizing deployments somewhat more complex...so maybe the fix for this is not about more process or more unit tests, but a small architecture change that centralizes message construction?

from socket.io-redis-adapter.

@toblerpwn huh thanks for the response, but I was faster by seconds :D anyway, there should be info in readme that it works with specific versions, and tests were make for specific version of socket.io-redis (talking about socket.io-emitter), then it will be more clear, cause I had to brake down both packages, check tests and compare package.json to find the issue. So the lists of compatible packages with their versions would be good enough, at least for me.

from socket.io-redis-adapter.

@toblerpwn obviously the key is to always pin modules to versions and pay attention to version bumps. Perhaps we should have done 1.0.0 for -redis since it was breaking, and 1.0.0 for emitter. I'll do that now. I apologize for the disruption.

from socket.io-redis-adapter.

Done 💥🎉

from socket.io-redis-adapter.