OneJS lets coders convert NodeJS projects into single, stand-alone files

I've been using a very similar tool, browserify to do the same thing. The great thing about browserify is it already comes with core node.js library support, as well as an http module wrapper.<p>With tools like this, I love being able to modularize my client-side code using CommonJS modules and running JS test from the command line using tools like Vows and Buster.js. I also love being able to declare dependencies on npm modules. It's just as easy as testing and writing Ruby code with rubygems and rspec.<p>The only issue that still bothers me is that nearly every DOM querying/manipulating library out there assumes there's a global window or document object. This means I have to stub it out in any CLI tests I run and then make sure jquery or whatever is referencing a virtual window I create with jsdom instead of the global stub.<p>I have a few project using vows/npm/browserify for reference if anyone is interested. A FF/Chrome/Safari plugin: <a href="https://github.com/brighterplanet/careplane" rel="nofollow">https://github.com/brighterplanet/careplane</a> A simple SPI app: <a href="https://github.com/brighterplanet/hootroot1" rel="nofollow">https://github.com/brighterplanet/hootroot1</a>

I've been looking at Node recently and I'm struggling to get my head around the run both on server and client methodology. I understand why it's useful to define model classes and include the file in both places, however I don't really see how this extends to the rest of the app. This tool seems to imply that you join all the modules of the app together into one file, which you can then include on the client - but surely there'd be code that you don't want included in this (like the server-side of websocket communication)?<p>Does anyone have any articles that can help me to fill the gaps?

Interesting. From what I can see, it just tricks any CommonJS style module into thinking that the module and exports variables are available; and that it's running in a node like environment. Things like accessing the file system and http wont' work, but that doesn't seem to be what it's meant for - it's more "write your client side js in a testable common js format, declare dependencies like backbone and underscore, and you'll get a neat little browser runnable package at the end".

<i>sigh</i> If I had known about this a week ago, I could have avoided a whole lot of hardship dealing with Require.js + node_jasmine + NPM... three complex things that were never really meant to work together. But I can see this as being really groundbreaking, kind of sidestepping the whole AMD vs. CommonJS protocol fragmentation and offering NPM as a way to distribute code meant to be bundled for clients!

I wish I had known about this earlier. In a recent project, I had to come up with a pretty ugly hack to make my script both Node.js and browser compatible: <a href="https://github.com/olalonde/kmeans.js/blob/master/lib/kmeans.js#L154" rel="nofollow">https://github.com/olalonde/kmeans.js/blob/master/lib/kmeans...</a>