Add io.js support #564

rvagg · 2015-01-17T03:09:21Z

fixes #563

Added a Makefile and a couple of devdeps to form a functional test that can be used to test compatibility on both Node and io.js, also in the form of a Docker image so you can run the tests on Linux without having install both runtimes locally.

othiym23 · 2015-01-17T23:27:23Z

lib/install.js

@@ -21,6 +21,8 @@ var fs = require('graceful-fs')
  , minimatch = require('minimatch')
  , mkdir = require('mkdirp')
  , win = process.platform == 'win32'
+  , runtime = semver.parse(process.version).major < 1 ? 'node' : 'iojs'


Longer-term, I'd really like to see iojs add an "iojs" property to process.versions so this test, which feels like a flaky heuristic that somebody, somewhere is going to forget about at some point, with unpredictable, but probably dire, consequences, can go away.

Agreed. This is pretty lame.

discussion here nodejs/node#491

TooTallNate · 2015-01-18T03:20:30Z

General comment: this seems like a departure from being "node-compatible". Why is changing the build file names so necessary?

othiym23 · 2015-01-18T04:14:54Z

I proposed nodejs/node#491 to improve the tests for whether node-gyp is being run against iojs or node.

isaacs · 2015-01-18T04:33:34Z

Just so I'm clear, changing the build filenames is because io.js is shipping as a binary named "iojs" and only symlinked to "node", right?

It seems like, rather than key on the version or rely on a process.versions.iojs, we might want to add some kind of API in iojs for "What is the build filename target?", which we can also add to Node.js, or any other forks/distros in the future.

That might also actually bring peace to any remaining debiants who still call it "/usr/bin/nodejs".

TooTallNate · 2015-01-18T04:35:39Z

@isaacs Possibly something like this?

path.basename(fs.realpathSync(process.execPath))

isaacs · 2015-01-18T04:35:48Z

In the very short term, it seems like a version number switch is the only option before us, and in the medium term, adding a one-off flag for iojs is probably easier than getting something into Node, so +1 from me for pragmatism on both counts, as long as we don't lose sight of cleaner solutions to the core meta-problem.

Tests and everything else about this pull req are awesome.

isaacs · 2015-01-18T04:38:49Z

@TooTallNate Actually you don't even need the realpath, since execPath is already realpathed.

$ which node
/usr/local/bin/node

$ node
> process.execPath
'/usr/local/bin/iojs'

rvagg · 2015-01-18T05:07:51Z

execPath is problematic on Windows, we currently have a link but a stub node.exe was planned; I don't know if that's still on the table, @piscisaureus

rvagg · 2015-01-18T05:11:25Z

re build filenames - we're not going to get people to download node-v1.0.2.tar.gz to get io.js, it's a different product and is Node-compatible (ish) but there's a limit to what we can do. Remember that Joyent were the ones that forced us to change from "node-forward" to io.js because of tradmark threats so we need some differentiation.

isaacs · 2015-01-18T05:31:15Z

If process.execPath isn't an option, then I'd strongly prefer a more full-featured process.release option which could answer these questions explicitly, rather than inferring from the version number.

rvagg · 2015-01-18T05:59:33Z

process.release:

{
  source: "https://iojs.org/dist/v1.0.2/iojs-v1.0.2.tar.gz"
  headers: "https://iojs.org/dist/v1.0.2/iojs-v1.0.2-headers.tar.gz" # fictional but easy
  lib: "https://iojs.org/dist/v1.0.2/win-x64/iojs.lib" # only on Windows
}

Then node-gyp could even support nightlies.

TooTallNate · 2015-01-18T08:22:54Z

Very nice @rvagg :)

piscisaureus · 2015-01-18T17:30:07Z

execPath is problematic on Windows, we currently have a link but a stub node.exe was planned; I don't know if that's still on the table, @piscisaureus

The stub trick I wanted to use turned out to be a bit problematic (issues with the stack protection cookie; ask me on irc for details.) The hard link solution we have now seems to work fine, so I want to stick to that.

{
source: "https://iojs.org/dist/v1.0.2/iojs-v1.0.2.tar.gz"
headers: "https://iojs.org/dist/v1.0.2/iojs-v1.0.2-headers.tar.gz" # fictional but easy
lib: "https://iojs.org/dist/v1.0.2/win-x64/iojs.lib" # only on Windows
}

That seems like a nice solution.
I'd still like to ship the headers plus lib file in the installer so no download would be necessary at all.

rvagg · 2015-01-18T22:50:26Z

headers are shipped with all distros but Windows currently, they have been from somewhere in Node 0.10, but nobody has put in the work to make node-gyp aware of them.

However, even if we do use installed headers there's no guarantee that they are actually going to be available on the system (plain binary install, stripped-down installer of some kind, manual install), so there needs to be a facility to fetch the headers anyway.

XadillaX · 2015-01-19T03:21:48Z

➜  thmclrx git:(master) node --help
Usage: node [options] [ -e script | script.js ] [arguments]
       node debug script.js [arguments]

Options:
  -v, --version        print node's version
  -e, --eval script    evaluate script
  -p, --print          evaluate script and print result
  -i, --interactive    always enter the REPL even if stdin
                       does not appear to be a terminal
  --no-deprecation     silence deprecation warnings
  --throw-deprecation  throw an exception anytime a deprecated function is used
  --trace-deprecation  show stack traces on deprecations
  --v8-options         print v8 command line options
  --max-stack-size=val set max v8 stack size (bytes)

Environment variables:
NODE_PATH              ':'-separated list of directories
                       prefixed to the module search path.
NODE_MODULE_CONTEXTS   Set to 1 to load modules in their own
                       global contexts.
NODE_DISABLE_COLORS    Set to 1 to disable colors in the REPL

Documentation can be found at https://iojs.org/

here you can see iojs.

so just run node --help and you can judge whether it's iojs or nodejs.

fengmk2 · 2015-01-21T04:12:35Z

lib/install.js

@@ -21,6 +21,8 @@ var fs = require('graceful-fs')
  , minimatch = require('minimatch')
  , mkdir = require('mkdirp')
  , win = process.platform == 'win32'
+  , runtime = semver.parse(process.version).major < 1 ? 'node' : 'iojs'
+  , defaultDisturl = runtime == 'node' ? 'http://nodejs.org/dist' : 'https://iojs.org/dist'



Any idea to support nvm custom dist url env by default? https://github.com/creationix/nvm/blob/master/nvm.sh#L73

@fengmk2 would this be to support mirrors, like in China? I'm tinkering around in there currently and it wouldn't be hard to bring in custom URLs from where my local version is at.

Not only for mirrors, but also can be used in private NPM services. @rvagg

@rvagg yes, it will be very helpful for us.

inspect process.release object for details about the platform and where to get source files

fengmk2 · 2015-03-11T03:49:19Z

I temporary use pangyp to build io.js and nodejs cpp module now.
Required npm@>2.7.0

$ npm i -g pangyp
$ npm --node-gyp=$your-npm-global-dir/pangyp/bin/node-gyp.js

leecade · 2015-03-11T06:00:14Z

@fengmk2 出手 PR 啊, 哈哈

XadillaX · 2015-03-11T06:03:10Z

@leecade siwujidan yong zhongwen zhende haome?

trevorlinton · 2015-04-07T02:32:00Z

Curious question... Why is the node native module system requiring a CRT//DllMain type initialization?

Couldn't NODE_MODULE macro be changed to define a stub "#modulename#_register" that returns the initialization function (rather than trying to run the node_module_register from within #modulename#register" that then gets ran and passed the options exports?

The current method relies on a very smart dynamic link loader thats transitive (and OS X is very much so) but with Windows and statically linking the node.lib its creating a lot of sticky situations where the proc addresses are being hard coded for, i'm not sure why.

Granted, i may not fully understand this but it seems like theres a simple non-breaking change that could be made if both node.js and io.js agreed to mutually change the definition of NODE_MODULE macro.

Or just have the NODE_MODULE macro kick out symbols for the old way and the new way, and node.js can continue doing whatever it wants, and others like io.js or tint can successfully register modules on windows.

Thoughts?

hanzhao · 2015-04-18T11:29:23Z

Why this pr isn't merged so far?

mhart · 2015-04-19T21:14:14Z

lib/install.js

+    return callback(e)
+  }
+
+console.log(release)


Remove this (I assume?)

nodejs/node-gyp#564 suggests this might fix the io.js build.

deepsweet · 2015-08-09T05:37:40Z

does pangyp solution work for io.js@3?

JCMais · 2015-08-13T01:39:27Z

@deepsweet yes

rvagg · 2015-09-04T13:57:34Z

new impl, using process.release and taking convergence into consideration #711

This was referenced Jan 17, 2015

node-gyp rebuild not working nodejs/node#433

Closed

deps: upgrade npm to 2.2.0 nodejs/node#479

Closed

othiym23 reviewed Jan 17, 2015
View reviewed changes

othiym23 mentioned this pull request Jan 18, 2015

src: add process.versions.iojs nodejs/node#491

Closed

othiym23 mentioned this pull request Jan 18, 2015

Working on 1.0.0 nodejs/node#253

Closed

added iojs support, added test

e865c0d

rvagg mentioned this pull request Jan 18, 2015

npm install fails with iojs v1.0.1 Level/leveldown#141

Closed

rvagg mentioned this pull request Jan 18, 2015

src: introduce process.release object (WIP) nodejs/node#493

Closed

othiym23 mentioned this pull request Jan 20, 2015

How do you verify npm is compiled against iojs nodejs/node#426

Closed

am11 mentioned this pull request Jan 20, 2015

io.js 1.1 support sass/node-sass#627

Closed

fengmk2 reviewed Jan 21, 2015
View reviewed changes

fengmk2 mentioned this pull request Jan 21, 2015

support io.js? #561

Closed

cb1kenobi mentioned this pull request Jan 23, 2015

Adds iojs support tidev/node-ios-device#1

Closed

add process.release support

3b49ef8

inspect process.release object for details about the platform and where to get source files

piscisaureus mentioned this pull request Mar 25, 2015

node-gyp: allow node.exe/iojs.exe to be renamed nodejs/node#1251

Merged

trevorlinton mentioned this pull request Apr 7, 2015

Unable to load native modules on Windows x64 trueinteractions/tint2#110

Open

othiym23 mentioned this pull request Apr 9, 2015

npm up -g breaks npm (for iojs) nodejs/node#1263

Closed

mickhansen mentioned this pull request Apr 16, 2015

iojs-full without upgraded npm mhart/alpine-node#1

Closed

mhart reviewed Apr 19, 2015
View reviewed changes

lib/install.js

return callback(e)

}

console.log(release)

Copy link

Contributor

mhart Apr 19, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this (I assume?)

am11 mentioned this pull request May 3, 2015

Create a troubleshooting guide sass/node-sass#921

Merged

shinnn referenced this pull request in BrowserSync/browser-sync May 5, 2015

fix(utils): remove useless resolveRelativeFilePath method

4b6c281

This was referenced May 5, 2015

Implements support for node 0.12.x c4milo/node-inotify#53

Merged

Some refactoring has to happen in order to continue supporting newer node.js versions c4milo/node-inotify#46

Closed

TakenPilot mentioned this pull request May 14, 2015

use pangyp instead abbr/deasync#15

Closed

TooTallNate mentioned this pull request May 31, 2015

Support iojs directly in node-gyp #640

Closed

papandreou added a commit to assetgraph/assetgraph that referenced this pull request Jun 27, 2015

Travis: Don't install npm in the before_install hook.

c39485d

nodejs/node-gyp#564 suggests this might fix the io.js build.

papandreou added a commit to assetgraph/assetgraph-builder that referenced this pull request Jun 28, 2015

Travis: Don't install npm in the before_install hook.

1e1f187

nodejs/node-gyp#564 suggests this might fix the io.js build.

rvagg mentioned this pull request Jul 3, 2015

Collaborator Checkin / 2015-07-02 → 2015-07-09 nodejs/node#2097

Closed

gabeio mentioned this pull request Jul 20, 2015

fix install: add iojs support #669

Closed

thomasjo mentioned this pull request Jul 29, 2015

Upgrade to Electron v0.30.6 atom/atom#7877

Merged

20 tasks

Fishrock123 added the io.js label Aug 22, 2015

Fishrock123 mentioned this pull request Aug 23, 2015

The node-gyp and io.js meta-issue #701

Closed

rvagg closed this Sep 4, 2015

rvagg deleted the iojs branch September 4, 2015 13:57

takeratta mentioned this pull request Jun 20, 2023

[Snyk] Security upgrade semver from 5.3.0 to 7.5.2 takeratta/node-gyp#1

Open

serveryang mentioned this pull request Jun 21, 2023

[Snyk] Security upgrade semver from 5.3.0 to 7.5.2 serveryang/node-gyp#5

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add io.js support #564

Add io.js support #564

rvagg commented Jan 17, 2015

othiym23 Jan 17, 2015

TooTallNate Jan 18, 2015

rvagg Jan 18, 2015

TooTallNate commented Jan 18, 2015

othiym23 commented Jan 18, 2015

isaacs commented Jan 18, 2015

TooTallNate commented Jan 18, 2015

isaacs commented Jan 18, 2015

isaacs commented Jan 18, 2015

rvagg commented Jan 18, 2015

rvagg commented Jan 18, 2015

isaacs commented Jan 18, 2015

rvagg commented Jan 18, 2015

TooTallNate commented Jan 18, 2015

piscisaureus commented Jan 18, 2015

rvagg commented Jan 18, 2015

XadillaX commented Jan 19, 2015

fengmk2 Jan 21, 2015

rvagg Jan 22, 2015

XadillaX Jan 22, 2015

fengmk2 Jan 22, 2015

fengmk2 commented Mar 11, 2015

leecade commented Mar 11, 2015

XadillaX commented Mar 11, 2015

trevorlinton commented Apr 7, 2015

hanzhao commented Apr 18, 2015

mhart Apr 19, 2015

deepsweet commented Aug 9, 2015

JCMais commented Aug 13, 2015

rvagg commented Sep 4, 2015

Add io.js support #564

Add io.js support #564

Conversation

rvagg commented Jan 17, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TooTallNate commented Jan 18, 2015

othiym23 commented Jan 18, 2015

isaacs commented Jan 18, 2015

TooTallNate commented Jan 18, 2015

isaacs commented Jan 18, 2015

isaacs commented Jan 18, 2015

rvagg commented Jan 18, 2015

rvagg commented Jan 18, 2015

isaacs commented Jan 18, 2015

rvagg commented Jan 18, 2015

TooTallNate commented Jan 18, 2015

piscisaureus commented Jan 18, 2015

rvagg commented Jan 18, 2015

XadillaX commented Jan 19, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fengmk2 commented Mar 11, 2015

leecade commented Mar 11, 2015

XadillaX commented Mar 11, 2015

trevorlinton commented Apr 7, 2015

hanzhao commented Apr 18, 2015

Choose a reason for hiding this comment

deepsweet commented Aug 9, 2015

JCMais commented Aug 13, 2015

rvagg commented Sep 4, 2015