I Am Profoundly Sorry to Introduce express-unstable and connect-unstable

‹prev | My Chain | next›

I shift gears today to solve my express-spdy installation problem. With the release of SPDY Book imminent, I need the express-spdy installation to be as easy as possible. Unfortunately, it already needs a compiled, edge-openssl. I would prefer not to require a custom node.js install, but that is what I am faced with.

My dilemma is this. The node-spdy package depends on features in node 0.5.0-pre or later. The express.js and connect packages (on which express-spdy is dependent) only support node before 0.5.

Prior to the official release of 0.5, one could compile node from the github repository and use express-spdy. This worked because, at that point, the version of node was 0.5.0-pre (less than 0.5) which was good enough for express. Once node hit 0.5, however, connect would no longer install.

To workaround, I could tell readers to checkout a specific SHA-1 in the git repository, but that feels hackish. Instead, I choose to support express and connect on 0.5 myself--in the form of express-unstable and connect-unstable packages.

I feel bad about this, I truly do, but I see no better way of making the express-spdy install easy on readers. So...

I follow along with the Github guide to forking a repos and add the real connect as my upstream:

➜  connect git:(master) git remote add upstream git://github.com/senchalabs/connect.git   
➜  connect git:(master) git fetch upstream
remote: Counting objects: 268, done.
remote: Compressing objects: 100% (84/84), done.
remote: Total 222 (delta 160), reused 200 (delta 138)
Receiving objects: 100% (222/222), 31.01 KiB, done.
Resolving deltas: 100% (160/160), completed with 34 local objects.
From git://github.com/senchalabs/connect
 * [new branch]      1.x        -> upstream/1.x
 * [new branch]      features/staticProvider-cache -> upstream/features/staticProvider-cache
 * [new branch]      gh-pages   -> upstream/gh-pages
 * [new branch]      master     -> upstream/master
From git://github.com/senchalabs/connect
 * [new tag]         1.6.0      -> 1.6.0

I then merge in the changes from upstream since I forked my version of connect:

➜  connect git:(master) git merge upstream/master
Updating 36986a2..93f999f
Fast-forward
 History.md                  |    8 ++
 Readme.md                   |    7 ++-
 examples/csrf.js            |   36 ++++++++++
 lib/connect.js              |   95 +++++++++-----------------
 lib/https.js                |   47 ------------
 lib/index.js                |    2 +-
 lib/middleware/compiler.js  |  163 -------------------------------------------
 lib/middleware/csrf.js      |  105 +++++++++++++++++++++++++++
 lib/middleware/directory.js |    1 +
 lib/middleware/logger.js    |    6 +-
 lib/patch.js                |   76 ++++++++++++--------
...
 30 files changed, 463 insertions(+), 603 deletions(-)
 create mode 100644 examples/csrf.js
 delete mode 100644 lib/https.js
 delete mode 100644 lib/middleware/compiler.js
 create mode 100644 lib/middleware/csrf.js
 rename lib/{http.js => proto.js} (82%)
 create mode 100644 test/common.js
 delete mode 100644 test/compiler.test.js
➜  connect git:(master) gp origin master
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:eee-c/connect.git
   36986a2..93f999f  master -> master

Now, I update the package.json file that will publish to npm. I am trying to strike a balance here between avoiding the appearance of stealing connect while also ensuring that no one bothers the real connect guys with support requests should they happen across this. Let me be clear:

I am in no way affiliated with connect. They are awesome and this work is entirely their own. Most importantly: DO NOT BOTHER THEM WITH SUPPORT REQUESTS!!!!

Anyhow, in the package.json, I change the name of the npm package:

-  "name": "connect",
+  "name": "connect-unstable",

I change the description to reflect the non-association with the real connect middleware:

-  "description": "High performance middleware framework",
+  "description": "Unstable, tracking fork of the real connect middleware.  Only use if you really, *really* need node 0.5+.",

I point the repository to my fork:

-  "repository": "git://github.com/senchalabs/connect.git",
+  "repository": "git://github.com/eee-c/connect.git",

I hate to make the next change, but I do not want anyone bothering TJ about this package, so I assume authorship even though I have made no actual code commits myself:

-  "author": "TJ Holowaychuk  (http://tjholowaychuk.com)",
+  "author": "Chris Strom  (http://eeecomputes.com)",

And lastly, I make the change that I set out to make in the first place:

-  "engines": { "node": ">= 0.4.1 < 0.5.0" }
+  "engines": { "node": ">= 0.4.1" }

With that, I am ready to publish:

➜  connect git:(master) npm publish
npm WARN Sending authorization over insecure channel.

The warning aside, "my" package is now published:



I do the same for express-spdy, but do my work in the 2.x branch since it seems that they have already begun to transistion to node 0.5+.

After that, I re-publish express-spdy and connect-spdy with dependencies on express-unstable and connect-unstable. I look forward to being able to get off of this in the future.

Now, I install express-spdy under node 0.5.2 on my VM:

cstrom@debian:~/node-spdy-example$ `which node` --version
v0.5.2
cstrom@debian:~/node-spdy-example$ npm install express-spdy
> zlibcontext@1.0.7 install /home/cstrom/node-spdy-example/node_modules/express-spdy/node_modules/spdy/node_modules/zlibcontext
...
'build' finished successfully (0.893s)
express-spdy@0.0.3 ./node_modules/express-spdy 
├── express-unstable@2.4.3 (mime@1.2.2 qs@0.3.0 connect-unstable@1.6.0)
├── connect-spdy@0.0.3 (connect-unstable@1.6.0)
└── spdy@0.1.1
cstrom@debian:~/node-spdy-example$ npm ls
/home/cstrom/node-spdy-example
└─┬ express-spdy@0.0.3 
  ├─┬ connect-spdy@0.0.3 
  │ └─┬ connect-unstable@1.6.0 
  │   ├── mime@1.2.2 
  │   └── qs@0.3.0 
  ├─┬ express-unstable@2.4.3 
  │ ├── connect-unstable@1.6.0 
  │ ├── mime@1.2.2 
  │ └── qs@0.3.0 
  └─┬ spdy@0.1.1 
    └── zlibcontext@1.0.7 

Unfortunately, that is not quite the end of the story. When I actually try to run things, I find that all of the require('express') and require('connect') are now broken. After searching and replacing them with require('express-unstable') and require('connect-unstable') in express-unstable, connect-unstable, express-spdy, and connect-spdy, I am finally able to install (without changing the express-spdy installation instructions) and run an express-spdy app on node 0.5.2:



Yay! It was a little touch and go there for a while, but it's good to have that item checked off from my TODO list. For now, it's back to finishing off SPDY Book.


Day #85