Skip to content

v0.5.1

Choose a tag to compare

View all tags
@electrohyun electrohyun released this 23 Aug 15:00
v0.5.1
0d6b415

smocket. Test socket.io without a server. Sweet setup, rocket speed.

What matters in this one

Smocket 0.5.1 adds an explicit SharedWorker path for frontend development across several browser tabs.

Pages using the same origin, browser profile, module worker URL, and worker name can share one caller-owned, in-browser Smocket server while retaining separate socket identities.

The synchronized packages add two public entry points:

  • attachSharedWorker from smocket/shared-worker
  • connectSharedWorker from smocket-client/shared-worker

Install the exact pair together:

npm install -D smocket@0.5.1 smocket-client@0.5.1

Multi-tab frontend workflow

The new SharedWorker guide and lobby example demonstrate connection admission, rooms, broadcasts, acknowledgements, ordered delivery, explicit disconnect, page close, and participant cleanup across three Chromium pages.

The Runnable Drawing Game runs the same React game in three pages. Its framework-independent application handler is registered with either:

  • one in-browser Smocket server hosted by a SharedWorker; or
  • a real Node.js HTTP and Socket.IO server.

Both modes cover distinct socket ids, countdown, sender-excluded strokes, chat, guess acknowledgements, one shared round result, page close, refresh, and a repeated clean run. The browser UI, event types, game state, and application handler stay the same; only the worker/page or Socket.IO server/client bootstrap changes (#393, #395).

Corrected observable results

These corrections match results exercised against Socket.IO 4.7.5 and 4.8.3:

  • Connection admission: admission hooks could begin before connect() returned. Callback auth, dynamic namespace matching, and namespace middleware now begin after the client factory returns while queued attempts remain cancellable (cases, #362).
  • Repeated middleware completion: repeated calls to the same continuation were previously collapsed. Repeated acceptance now completes the lifecycle repeatedly on one server Socket, while acceptance followed by rejection preserves the observed teardown and client-error sequence (cases, #363).
  • Acknowledgement teardown: retained acknowledgement callbacks could outlive a disconnected socket or closed server. Teardown now invalidates those callbacks while already queued synchronous delivery may finish during the drain (cases, #364).
  • Timed callbacks: delivered timed callbacks could remain pending across disconnect paths. They now settle exactly once with the Socket.IO disconnected error, and expired buffered packets are removed instead of accumulating or being delivered later (disconnect cases, timeout cases, #365).
  • Client modifiers: an outgoing observer or payload-encoding failure could consume a pending client modifier too early. The modifier now remains available until an emit is dropped as volatile, buffered, or successfully encoded and scheduled (cases, #366).

Upgrade and scope

Keep smocket and smocket-client on the same exact version. The Node.js requirement remains >=20, the existing Socket.IO compatibility promises remain in place, and public 0.5.0 TypeScript consumers compile against the 0.5.1 declarations.

The applied ADR 0019 rows are:

  • A change to a smocket-only API (section B) for the compatible SharedWorker entry points, using ordinary semantic versioning.
  • A correction toward measured real behaviour with an observable change for the delivery and lifecycle corrections above.

The repository's 0.x version mapping places both classifications in 0.5.1.

The SharedWorker facade is deliberately narrow. It supports in-memory frontend development within one browser profile; it does not provide production transport, authentication, persistence, automatic reconnection, database access, cross-device communication, scaling, or the complete Socket.IO Client API. Worker termination or restart loses its state.

A deployed application replaces the page bootstrap with socket.io-client and verifies its real backend separately while retaining the supported event types and application handler flow.

Published packages

The release workflow independently installed and exercised the exact published pair outside the repository checkout:

The canonical published consumer now follows the same synchronized pair.

Full Changelog: v0.5.0...v0.5.1

Assets 2
Loading