SocketStream says dependencies are peer, and pins twenty-two of them

A notice from 2019 on code touched in 2022

The first thing the file says is that the project is no longer worked on, that the code is there for anyone who wants to look, and that there are lots of other Node.js web application frameworks to consider instead. The notice is signed and dated, mid-May 2019. What the repository does not reconcile is that the default branch received commits until March 2022, nearly three years after that notice was written. So the state of the project is ambiguous in the way abandoned projects usually are: the author stepped down publicly, work continued, and neither the notice nor the branch records what that work was. The project is not archived on the platform, it publishes no releases, and its licence is MIT, which means the code is free to read and free to reuse with none of the guarantees attached.

The newest release was unstable and the advice was to stay behind

The introduction states the latest release as 0.5.3 and marks it unstable, then advises existing installations to remain on 0.4.5 for a while, describing that version as the most backwards compatible and the best covered by tests and saying it should be ready for production. So the last published line was explicitly not the one to run, and the one to run was a full minor version earlier. The forward-looking paragraph explains why: coming releases would see a lot of changes to accommodate new transport options in modern browsers and mobile apps, with the API remaining largely the same but with bound to be changes. That is a plan for a rewrite, described in the past tense, and the version table it produced is the closest thing the repository has to a status page.

Peer dependencies claimed, exact pins shipped

One of the bullets under the batteries-included heading says dependencies are peer, so you pick the versions you want to use. The package manifest lists twenty-two dependencies, most of them pinned to an exact version rather than a range: an API tree builder, an async library, a CSS minifier, a Redis session store, a CSRF middleware, a debug logger, an event emitter, a glob, a match library, a URL parser, a Redis client, a static file sender, an id generator, a JavaScript minifier, a merge helper, a UUID library and a command line parser, all at specific old versions. The contradiction is not subtle, and it has a concrete consequence: an application cannot easily upgrade one of them, which is the entire reason the peer claim was made.

The Redis version appears on both sides of the upgrade

There is a second, sharper version of the same problem in the upgrade notes. To move from the 0.3 or 0.4 lines to 0.5, the README says several major dependencies were moved out for stability and asks you to add them to your own manifest, giving five of them with versions attached: the cookie session module at the 0.5 line, two engine.io packages at the same pinned version, a Redis client and a connect version. The Redis client it asks you to install is listed in the framework's own dependencies at exactly that version. So the instruction is to add a package the framework already carries, at a version the framework has already chosen. Anyone following the upgrade path literally ends up with two copies of the same client, which is exactly the class of problem a dependency claim is supposed to prevent.

Two build tools and two linters in one root

The root directory is a snapshot of a project mid-migration rather than one with a single toolchain. A Grunt build file and a gulp file sit side by side. Both a source directory and a library directory exist. A template directory holds the project scaffold the command line tool copies out. Linting is configured twice, once through a JavaScript linter with its own ignore file and once through a hosted style checker with its own configuration, which is why a single change can be judged by two sets of rules. Continuous integration is configured through a Travis file, and the package scripts layer npm commands on top. None of this is wrong for a project of its age, and all of it is a cost for anyone who wants to change the build rather than use it.

Streaming described as dust over REST

The design position is stated more clearly than the tooling. A good REST API remains the right answer for many scenarios, web pages remain based on HTTP, and streaming is described as pixie dust sprinkled on top of that, to be added gradually with the REST structure kept as the central point. The integration list follows from it: built-in transport integration for two realtime libraries, add-ons that drop in without configuration and choose between cookie and token authentication, and live reload with optional support for two template languages and other transpilers. The framework's claim to usefulness is that rich realtime interfaces are hard to keep tidy, and that these integrations are what keeps them tidy. The cost of that claim is a dependency tree like the one above.

Asset packing from the 2014 generation

Deployment support is the other headline, and the manifest dates it. Integrated asset packing and CDN support are implemented with a JavaScript minifier at version 2.4 and a CSS minifier at version 3.3, both pinned. The bundler is described as CommonJS with ES6 on the way. Formatter integration is listed for three stylesheet languages and two template languages, template engines for four front-end libraries including React and Angular, and the project management features are a sensible place to put everything, a production deployment skeleton and good debugging output. Read as a whole, the feature list describes a framework that tried to be the only thing in a project directory, which is why the install is global and the generated app is a starting point rather than a dependency.

Who wrote it, and who shipped a product on it

The team section credits an owner, an original creator and four core contributors. The applications section is the more telling part, because it names five products built on the framework: a hosted dashboard and widget product, a slide deck design tool from sketches that was a Y Combinator company, an interactive documentary that was nominated for an Emmy, a realtime cryptocurrency price site, and a booking engine for golf courses. The presentation list runs from a 2013 conference deck to a 2015 camp talk, and the video list starts at a 2011 conference in Portland and ends in 2013. That is the shape of the project's life in one paragraph: several years of real use, a peak around 2013, and a long tail of talks and side projects after the core work slowed.

Editorial conclusion

SocketStream belongs in a case study rather than in a dependency list. Its own file tells you to look elsewhere, its newest release was labelled unstable, and the version it recommends for production predates it by a full minor line. Read it for two things: how a 2011 to 2015 realtime framework handled transports, auth and asset packing, and what its dependency claims looked like before peer dependencies were normalised. If you do adopt it, pin to the version the README recommends rather than the version the manifest names, and expect a Redis client and an engine.io pair that the framework both ships and asks you to install.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases