🚀 Toward smocket v1.0.0: direction and priorities

[electrohyun]

Where smocket is now

With v0.4.2 released, smocket has entered the stretch toward its first stable release. The current goal is to release v1.0.0 by the end of August 2026.

Before turning every remaining idea into implementation work, I want to make the priorities behind that release visible. The direction is still open to refinement, but the reasoning, trade-offs, and follow-up work should be public.

Five lenses

The current discussion starts from five lenses. They are decision tools, not independent scores or finalized marketing claims.

Lens	Question
Fidelity	Does smocket reproduce the same observable results as real Socket.IO?
Extensibility	Can smocket grow without breaking that fidelity?
Reliability	Are those results continuously verified as Socket.IO and smocket change?
Productivity	Does smocket reduce the cost of writing and maintaining Socket.IO tests?
Sustainability	Can the promises and development model of smocket be maintained over the long term?

Fidelity remains the anchor. Convenience and extension work should not contradict the observable behavior that smocket claims to reproduce. Reliability asks how those results remain verified over time, while Productivity asks whether the resulting test workflow is actually worth using. Sustainability applies the same standard to the project itself.

Work toward v1.0.0

The current plan is to:

• define how the five lenses guide development and review decisions in durable documentation (docs: define how the five lenses guide development decisions #214);
• document how to choose between issues, Discussions, and documentation (docs: document how to contribute through issues, Discussions, and documentation #215);
• publish a public roadmap toward v1.0.0 (docs: publish the roadmap toward v1.0.0 #216);
• explain how development and validation continue after v1.0.0 (docs: define how development and validation continue after v1.0.0 #217);
• recover a larger application example from a realistic user workflow (docs: expand the chat room into an application workflow #113);
• decide how a standalone consumer of the published npm package should be maintained, including whether recurring downstream validation belongs in smocket CI or a separate public repository (docs: add a published-package sandbox for the chat room example #208);
• publish application-level Fidelity, Reliability, and Productivity findings as both a static report and an interactive site page (docs: publish an application case study comparing test support approaches #218).

The application work is not intended to duplicate the core conformance suite. The real/mock dual run remains the source of truth for declared Socket.IO behavior. A downstream consumer should instead expose packaging, setup, integration, documentation, and maintenance problems that appear only when smocket is used from outside its own workspace.

How to contribute

Real project experience is especially useful during this stage. The contributing guide keeps the current routes and direct links in one place.

• Open a bug report when smocket produces a different observable result from real Socket.IO.
• Open a feature request when a required Socket.IO behavior is missing or when an extension could improve testing without breaking fidelity.
• Use Discussions for broader use cases, API direction, workflow friction, and evidence that would make smocket easier to trust.
• Open a documentation issue when the current guidance makes adoption or contribution harder.

Simple reports are welcome. You do not need to prepare a research plan or a complete reproduction before sharing a useful experience.

Tracking

#213 is the parent tracking issue for this direction. Its sub-issues carry the concrete decisions and deliverables listed above.

Feedback on the five lenses, their relative importance, missing v1 requirements, and real Socket.IO testing workflows is welcome here.