Comments (31)
is it a goal of iojs to be long-term compatible with node?
Initial releases, 100%, but being that we have no control over where Joyent will take their fork in the future we can't really commit to staying compatible with whatever they decide to do. If there is a divergence we might choose to deprecate the "node" binary which is one reason I think it's important to install the iojs binary as well.
from node.
I think that absent a node
alias or binary, iojs would be DOA.
+1 on being able to defer the decision on deprecating node
long term, also +1 on proactive thinking with doing an iojs
binary now
from node.
FFmpeg was forked into LibAV, LibAV used the same FFmpeg binary names without any issue, at the end LibAV diverged a lot from FFmpeg removing bunchs of functionalities and then they stopped using ffmpeg binary name but people already migrated their scripts to libav if they actually used libav.
I think that was the right approach on the long-term and short-term.
(The example is based on the fact that FFmpeg may be even bigger than node and it worked).
Other thing, I remember the name node is already used by other binary from the ham-community (reason why node is Debian-based systems is usually called nodejs
instead of plain node
. I think that won't happen with iojs
).
from node.
@ghostbar thanks for that story, it's incredibly relevant and puts to ease some of the concerns we've had.
from node.
mariadb
is another example of a fork that uses the same binary and directory naming conventions. Here's a web-page from their site:
The've also diverged, but are still mysql
.
from node.
Another thing that'll come up is the engines
field in package.json
. There needs to be a way to differentiate between node
and iojs
.
Let's say, I build a module or an app that depends on some of the newer v8 features, I'd need a way to communicate that to the modules's consumers or the PaaS (in case of an app) or whatever.
from node.
@klaemoโs point is important. And my 2ยข: it should be io
not iojs
in the engines, even if it breaks vertical align with node
.
from node.
While providing a node
alias and having an expectation of compatibility, is there some plan to track explicit compatibility? A map of say iojs 1.x => nodejs 0.12.x?
see #46
from node.
IMO node
was already too generic and as a consequence too bad, io
would make it worst. It's not like this project is the only thing that will make I/O in a system, so it should be iojs
.
from node.
fwiw, I just went through the mariadb-server
install when installing over mysql-server
on ubuntu using apt-get
and the install succeeded without any warnings what-so-ever. It basically over-wrote my mysql
install.
from node.
Good idea @kenperkins, interesting experiment.
from node.
@kenperkins that's because it uses the alternatives from Debian-based distros, where you can have it called the same way and link to mysql
based on the alternatives proposed.
It's the same way with generic names like editor
which in my case links to vim
but in the default system links to nano
.
from node.
There are already at least two programming languages named io, and any two-character name should be considered a no-go. I would be interested in hearing arguments in favor of "io" over "iojs" for the binary name, but I feel like I need convincing.
from node.
I don't think io
should even be a consideration. Way too generic.
from node.
+1 for iojs
in lieu of just io
from node.
๐ For iojs
.
from node.
people that really care will alias io='iojs'
anyways
from node.
io
has a higher probability of conflicting with other commands though
from node.
Noting the discussion here (re: the project's default command line name) may relate to the outcome of #118
from node.
Per today's TC meeting, the plan is to rename to binary to iojs
and ln -s iojs node
on install if a node
binary doesn't already exist. How to make the symlink work on Windows is up for discussion, see #140.
from node.
@bnoordhuis so that means that if node is already present, we won't do anything (wrt to the symlink, or removing node)?
I'm not sure I like the idea that depending on the state of the system, invoking node
may or may not result in the iojs
binary being executed.
I wonder if we'd be better off being more explicit in our behavior; a couple of options:
- Always fail to install if node is already present (i.e. conflict)
- Stomp on the node install and replace it with iojs (like mariadb)
Thoughts?
from node.
NAN requires executing 'node' to find the location of the header. Windows compatibility is the main source of problems when it comes to using multiple alternative names. nodejs/nan#70
from node.
@kenperkins After thinking about it some more, I fear that stomping on an existing install is probably the only workable approach. I didn't realize how much stuff the installer installs into $prefix/include and $prefix/lib and I don't think it's possible to detect whether that's from a joyent/node or iojs install.
from node.
Considering #249 and #42 where does this issue sit? Seems like in #249 a decision has been made, so I think that should be reflected here and maybe close this one?
from node.
Having iojs
alias back to node
with both binaries being available to call in the $PATH
, It's going to make packaging iojs
alongside node
hell. Completely understand and appreciate why it needs to be done, but I wiggle uncomfortably on the potential for iojs
and node
to just play the "let's override each other's links" game if they're installed side-by-side.
from node.
Maybe it would be good to semi-officially support/recommend version manages (nvm, n) as part of our website/README. Especially if we can get those projects to support iojs sooner than later. (Or fork our own.)
It could help people maintain both versions and have a clearer sense of which they are on.
from node.
+1 for creating our own version manager.
from node.
I'm pretty sure that's unnecessary, we have version manager authors/maintainers involved here and looking to make them work with io.js: nodejs/build#22
from node.
Don't fork the version manager; as @rvagg mentions there's plenty of interest and desire for the current package managers to stay current with trends in all the forks.
from node.
As long as io.js
supports the same things as node.js
- namely, curl
-able binaries + source, easy-to-consume-from-POSIX version URLs, and path-related environment variables, http://nvm.sh will definitely support io.js
.
What the project decides to do with the binary doesn't matter to me wrt nvm
, as long as it either stays backwards-compatible, or provides notice for breaking changes so nvm
can be updated.
from node.
There has been a bit of discussion in #28 about what to name the binary. This probably deserves it's own discussion.
The proposed approach
Is the plan to have the installer install an iojs binary and an alias to node?
presents some additional questions:
- how do node / iojs live side by side?
- is it a goal of iojs to be long-term compatible with node?
from node.
Related Issues (20)
- ESM mistaken for CJS despite --experimental-detect-module HOT 7
- intl.datetimeformat comma removed after version 20.11.1 HOT 8
- test-buffer-failed-alloc-typed-arrays test failures HOT 4
- wasi fast calls causes segfault on x86_64-linux when running a wasm32-wasi module
- Accept `Blob`s anywhere where a `Buffer` is currently accepted for writing HOT 1
- /usr/local/lib/nodejs
- Node.js
- parseArgs with type: "boolean" and default: true does not allow a false value HOT 4
- yarn install dependency package throw error"error Error: incorrect data check at Zlib.zlibOnError [as onerror] (node:zlib:189:17)" HOT 2
- ESM loader hooks in Workers no longer working since Node.js 22.2 HOT 7
- `fs.watch` doesn't listen changes of file containing JSON stringified if changes happen too quickly (behavior different with non JSON) HOT 1
- Node 20.13 --watch option breaks loader / preload of modules HOT 3
- `node:test` custom reporters get `test:stdout` and `test:stderr` events before `test:dequeue` HOT 9
- Strange behavior with `fs.watch` on file with JSON stringified -> first update isn't emitted if too fast after `fs.watch` HOT 6
- Rename or delete a watched test file will cause `MODULE_NOT_FOUND` error
- undefined reference to `v8::internal::trap_handler::RegisterDefaultTrapHandler()' HOT 3
- Incompatible ReadableStream TypeScript types HOT 1
- Document `[sub]process.channel.refCounted()` and `[sub]process.channel.unrefCounted()`
- This repositories devcontainer setup deletes all your other devcontainers HOT 2
- FixedCircularBuffer isFull(), isEmpty() and wrapping off by one HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from node.