Error: Cannot find module 'ws', module.js:338:15. node bin\server.js On Windows 7, Node v0.8.18

Lets make sure I'm not a bonehead first:
git clone repo, cd into server\express, npm install, cd bin, node server.js
npm install on package.json is smooth with some 304s (unmodified) and some WARNs on README.md.
If there's not an adherence to the standard Express server start protocol (npm install, node server.js), this will throw a curve-ball to many who are already familiar with the normal Express starting pattern.
With the addition of server-side plugin modules we've made the install more complex. We are discussing this on Issue #343. Perhaps we can make the plugin launch logic tolerant of incompletely installed plugins?
I've added a try-catch around the plugin server start code. This gets the server going and reports reasonable diagnostics. Client side of plugins are tolerant of server-side failures.
This try-catch worked for me (author).
Still throws errors for the plugins: linkmap, parse. Which I need more information about as there still seems to be a rather crucial error:
Here's the TypeError:

ps. Ward, thanks for jumping on that so quickly.
So, basically, you want to do npm install in the client directory, as well as the plugin directories that are failing. Your specific error to this issue is solved when you npm install in client.
Also, if you are trying to run this on windows, you will have to do some extra work. I was unable to make the ws library work on a windows host. I do not have Visual Studio 2008 installed, which I think is required for it to compile properly.
There are only a couple of plugins that have server-side parts. You should be able to ignore these for now since they don't interfere with launching the http server. Or, as @hallahan suggests, you could just npm install them.
The Factory plugin is the first one that is dynamically loaded. It looks like this isn't working for you. If you open chrome's network inspector you should see the client get /plugins/factory/factory.js. If you're not sure what you should see, try using the inspector on http://foobar.fed.wiki.org.
Hey guys, thanks for the pointers.
The problem is that factory.js holds/maintains an http statusText of 'pending' (0B/13B loaded). Might this happen because the .coffee is being compiled? - (@hallahan, is this what you're referring to above?).
I'll continue to trouble shoot this issue off & on.
I haven't seen this problem. Is there a client/plugins/factory/factory.js file?
The 'ws' module is short for web socket. This shouldn't have anything to do with factory as far as I know.
Just so you know, the the coffeescript is precompiled to js under the hood when you start node. Client side coffee is explicitly compiled, but server side, node does it when it starts up. Sometimes, I do expliclty compile it to help me out with debugging, but it's not needed.
There is a client/.../factory.js.
The current behavior is that the factory div (gray container) displays, however, none of the links appear inside of it, after about 6 minutes chrome cancels the request/GET fails.
The gray box comes from the css which has loaded. If I understand your situation, your server has never correctly served a plugin js file. So it does, core js and css but not plugin js. I'd guess you are invoking the server from the wrong place or with wrong arguments or something like that.
If I understand your situation, your server has never correctly served a plugin js file.
Not with the express server (on Windows) - the sinatra server (also on Windows) has a different problem (see issue #349 ), but otherwise appears to work.
Looking at the express server code, it looks as if the request for /plugins/factory/factory.js is handled at line 353 in server.coffee - and if so this looks different to how the sinatra server is handling it (the code referencing meta-factory.js there is commented out, at least in server.rb)!
There was a time that I foolishly did surgery on the factory.js code as it was served. @nrn duplicated this code in the express version. I rewrote the client side to simply request the menu contents, /system/factories.json, in a second server turnaround. The client is happy to work either way. However, It appears you are having trouble with code that we'd like to abandon.
Perhaps you would like to try implementing /system/factories.json in express? It is easier to test than lots else in SFW since you can call the new code directly with your browser:
http://fed.wiki.org/system/factories.json
Once this code works you can delete the special case handling of factorie.js in express just as I have in the sinatra version.
I'm sorry this has been such a rough path for you. I do appreciate the time you've put into it. I can't wait to see your first pull request. I'm happy to double check your work.
Let me know if you need anything working on this, I'd be glad to help.
This may take some time - I'm tempted to write up the instructions for getting the Sinatra server version running on Windows first, as that seem to be the simplest route for those of us on Windows to get a working version.
I'm going to have to revisit getting ws to install, I notice that there have been some updates on that over at einaros/ws since I last looked at this.
Ok, I'll fix this real quick then.
A quick update, not sure what my original problem with getting ws to compile was - it compiled with just some warnings about 'size_t' to 'unsigned int' and no definition for inline function 'v8::Persistent<T> v8::Persistent<T>::New(v8::Handle<T>)' - I suspect I was having an environment problem similar to that some have raised over at einaros/ws (having system32 missing from the path).
As well as running npm install run in the client, client\plugins, sever\express directories it also needs to be run in client\plugins\linkmap and client\plugins\parse.
Will add this to the windows readme over at #358