Repository navigation
node as an alias for iojs doesn't work #895
Description
Activity
The biggest issue I see here is that
iojsis a replacement fornodeand the methods by which people run multiple versions (nvm,nave,n) all set a current version (of node.js or io.js). This means that globally installed bins rely on this to know which versions to run against.People want to install a bin globally from npm once and then have that work with whatever platform they are currently usually globally (either io.js or node.js).
Even just the use of npm itself would be ambiguous with both io.js and node.js installed. When I do something like
npm install -g mocha, am I globally installing it with the currently active io.js install or the currently active node.js install? What if I try to install a native module locally? What version should it build against? How do I find the correct node-gyp? All these steps rely on shebangs on things in the path.The only way around that I can see is having iojs use differently named tools with different shebangs: ipm, io-gyp, etc. That adds some unwanted maintenance burden. Personally, I'd rather see that effort going toward resolving issues preventing merging with Node Foundation.
Maybe we're asking the wrong questions here.
Taking a step back, node.js & npm were never built to support parallel versions running side by side. io.js has inherited this and also cannot live effectively in parallel with other versions.
So, what would it look like if io.js/npm were built to allow multiple versions installed and working in parallel? My guess is that it would look something like the way we're handling conflicting versions of dependencies living in parallel, we localize them.
It's come up more than once, I think the last person who brought it up was @rauchg, but it could be better for applications to define the version of the platform they want locally and manage the installation/upgrade of it with
npm.If we think this a good idea it might be worth collaborating with npm on the NG work and try to ensure that the next version of the platform is built with this kind of thing in mind.
I think iojs should consider the multiple parallel versions scenario, specially in light of the frequent release cycle.
What about changing the binary name back to
nodeand getting rid of the symlink? As someone who wants to (and has to) support both pre-iojs and post-iojs libraries & tools, including CI tests in multiple CI systems, I'd strongly prefer io.js keeping the "node" binary name. REE and MRI use(d)rubyandgem, different JDK6 implementations usedjava, and different node versions usenode.In the meantime npm packages remain dependent on the binary name being 'node' because we claim that this is fully supported and it works most of the time.
Is that the real question here? Whether io.js should officially drop node-compatibility from its goals?
IMHO iojs should have its own binary name. not node.
What I've done in many years myself is to install node at different locations. And then all global installations also lives at that location.
Eg.
/path/to/node/v0.10.11/bin/node/path/to/node/v0.10.11/lib/node_modules/
/path/to/node/v0.8.28/bin/node/path/to/node/v0.8.28/lib/node_modules/And then I have a symlinked directory which is added to my path.
/path/to/node/current=>/path/to/node/v0.8.28/In addition I have some scripts which make it easy to switch between versions.
The drawback with this solution is that I have to reinstall global modules for each version of node I have installed. The benefit is that I never have problems with binary modules which need to be rebuildt.
io.js is just another version of node. Lets document that better and make the tools better at handling multiple version.
For folks working on npm packages, we need to test against both the latest stable Node, and the latest stable Io.js. So, it would be lovely if
nodeandiojscould live in harmony by default, side by side.At the moment, if you attempt to do this,
npmseems to get tangled and confused about its self-identity (although it still continues to work).npm WARN unmet dependency /usr/local/lib/node_modules/npm/node_modules/npm-package-arg requires semver@'4' but will load npm WARN unmet dependency /usr/local/lib/node_modules/npm/node_modules/semver, npm WARN unmet dependency which is version 2.3.0 npm WARN unmet dependency /usr/local/lib/node_modules/npm/node_modules/read-installed/node_modules/readdir-scoped-modules requires graceful-fs@'^3.0.4' but will load npm WARN unmet dependency /usr/local/lib/node_modules/npm/node_modules/graceful-fs, npm WARN unmet dependency which is version 3.0.2@jashkenas If you test against different versions (I'm assuming you'd be testing against more than just the one latest stable version), wouldn't a version switcher be the more appropriate solution:
nvm exec iojs npm test,nvm exec 0.10 npm test,nvm exec 0.12 npm test. with different binary names these kinds of cross-version tests become only more complicated:nvm exec ${NODE_VERSION} my-test-script.shsuddenly doesn't "just work" anymore unless the test script has switches/uses variables everywhere the binary name might be involved.maybe this is not the place, maybe it's already answered but I'm new to node, github etc. and iojs rocks!
- why keep pushing 'node' name ? anybody left doesn't know iojs ?
- how come npm doesn't have an iojs support (naming) ? is io.js temporary ? (hope its not!)
Typically Perl does not have an issue with multiple versions living side-by-side. Typically, if you were to follow the Perl Way(TM), scripts would always assume the executable is
process.argv[0]andnpmshould re-write the shebang when installing things intobin/.@dougwilson That works assuming that you'd only have perl scripts starting other perl scripts. But if you use bash scripts or Makefiles or python (sublime plugin) or ..., that approach is not enough.
Jenkins'
ArtifactArchiveris stillhudson.tasks.ArtifactArchiver. There's a cost to renaming stuff and I just don't see the gain in this case. There are already good and established tools to run multiple node versions "side-by-side". This is nothing new (even though the long time waiting for 0.12 might have made people forget...).- why keep pushing 'node' name ? anybody left doesn't know iojs ?
I work in a company with 15 developers. All of them know what Node.js is (even though our product is written in Java), but only me and another guy know about io.js.
Also, in addition to other points already highlighted, let's not forget all the tooling embedded in editors/IDEs.
For Windows users, this is not a matter of disliking the name or breaking in rare situations but it is breaking for all packages which depend on C++ module, which are built against io.js and executed with
nodethat comes packaged in iojs.msi (node.exe from io.js is a ditto mirror of iojs.exe, not a symlink, see #871). Also related: #751, #965.Please make sure whichever solution this discussion yield, it works on Windows as well.
Is this worthwhile bringing to the TC? it seems like quite an issue for windows users.
I don't think we have a question to ask of the TC here yet. I don't see a clear solution being presented and a TC discussion would end up being as much of a bikeshed as this is.
Nevermind for now. Let's see how things fare after 3d46fef.
Before releasing iojs 1.0 we decided that we'd support
nodeas an alias for iojs.The reasoning was that many npm packages hard-code the binary name to be 'node'.
This has upset people in different categories, generally the people that want to use iojs side-by-side with node complain about the (sym)link where others complain that the symlink solution doesn't work well enough.
In the meantime npm packages remain dependent on the binary name being 'node' because we claim that this is fully supported and it works most of the time.
I move to for alternative solutions asap and eventually deprecate the 'node' alias.
A couple places where a hard-coded node alias turns up: