Use "iojs" instead in NodeJSHelper

[vroad]

This will fix problem with latest version of io.js.
After applyng this fix, you'll be able to run lime app with "lime test" command.

I don't think it's not good idea to include node executables in repo, because users may want to use different version of Node.js(or io.js), and it's diffuclt to put latest binary of all platforms. Older binaries just makes size of git repo bigger.

[jgranick]

Ideally, I wanted to be able to wrap up Node.js support with no dependencies -- like how Neko works. The ideal scenario with Neko is that you can target it without having Neko on the user's system. It's a static executable. In order to do this, the tools include a known good version of Neko and bind it to the generated code.

If we rely upon Node being on the system, then it means that we've added a dependency for the user to use it. Maybe that's fine, though long-term, it would be nice (potentially?) to still support self-encapsulated builds of some kind, so that you could zip up the project and drop it on another machine without node installed.

Is io.js installed by default with Node, or are you thinking that both io.js and node.js should be installed on the system?

[vroad]

What do you mean by last sentence? io.js is fork of Node.js created by former Node.js development members, right?

[vroad]

I found this issue, which explains why native modules does not work when you launch io.js with "node" alias. Sadly, on Windows, it's not possible to change the name of io.js executable to another one because of this issue.
nodejs/node#751

After this problem is solved, maybe we could provide a build system like you said. But isn't node too big to include in git repo? Windows x86 version sizes more than 6MB.

...But node executables included in lime repo wasn't so big. Did you do something to make these executables smaller?

Node.js itself works without dependencies I think. What are the use of other files?

Either way, we should allow users to use different version of Node.js(or io.js) in case users want.

[jgranick]

Alright, for now, I'll include your pull as-is -- you're the one who has node.js support working, so I'd rather support your workflow than presuming my own, without even being able to test it myself.

I think the only thing that's really missing is probably a workflow where I am able to test the NDLL module, and precompile (?) it for each platform, or is that something you drop into the target project and let Node compile on-the-fly, somehow?

[jgranick]

Wow, this was a dangerous pull. I thought it just changed the NodeJSHelper, but I did not realize that you also removed all the node binaries. This is used in the HTML5 target to boot up an HTTP server. I just forced back to a previous commit and manually included the iojs change. Thanks 😄

[vroad]

You can install ndll addon with "npm install ndll" as I published source code to npm. You need to have some compiler installed to your computer, as "npm install" automatically launches node-gyp to build native addon.

[vroad]

It might be better to let npm compile native addon as its binary compatibility may lost in the future. We may even need to change the source code of ndll module if Node's api changes.