I'm downgrading node.js from v7.7.4 to v0.10.48 because I'm on a CentOS 6.5 server and apparently v0.10.48 is the latest it can handle. Are there issues with going backwards like this?
It should work
There are no issues in way that it will work just as well as it did when it was the current version.
But...
There will be issues with the compatibility of modules on npm. Many of the modules may not work. That is partially because Node v0.10 uses V8 v3.14 (for comparison the current Node versions use V8 v5.x) so a lot of modern JavaScript syntax doesn't work there.
Syntax
For details of what syntax works and what doesn't see:
http://node.green/
For example you will not be able to use a simple arrow functions:
const add1 = x => x + 1;
or even the const keyword for that matter. You will miss a lot of syntax that we now take for granted even on the frontend. Remember that io.js was forked from Node v0.12 mainly because it used such an outdated version of V8 - and it was literally years ago and was about a newer and much modern version than the one you want to use.
Core API
Also the core modules changed during that time changed a lot - compare:
https://nodejs.org/dist/latest-v0.10.x/docs/api/
https://nodejs.org/dist/latest-v7.x/docs/api/
Modules
Because current versions of Node support newer language syntax and have improved core API, a lot of the modules on npm will not work correctly or at all. Make sure that whatever module you use still supports Node v0.10 or use an old version that did support it. You may need to use shrinkwrap to downgrade a lot of sub-dependencies because even if you use an old version of a module that used to work on Node v0.10, it may still load the latest versions of its dependencies that don't work any more.
Security
Also there will be potential issues with bugs and vulnerabilities that will not get fixed. The v0.10 version manitenance ended on 2016-10-31 and the status of this version is currently: End-of-Life. The oldest version that is still maintained today (as of May, 2017) is 4.x.
See:
https://github.com/nodejs/LTS
Related
I've been using NVM for Windows to run two versions of Node on my system, the latest version and the LTS version. However, I haven't updated Node since installing NVM. I would like to update both versions to their current iterations (11.5.0 and 10.14.2 at the time of writing), ideally without having to reinstall all of my global packages for each. I know the original NVM has this capability with the --reinstall-packages-from flag, but it doesn't look like there's anything similar in NVM for Windows.
You're right, there's nothing similar in NVM for Windows. If it would be useful for you, you could always request it by opening an issue on the github page.
It sounds like you already know how to install 11.5.0 and 10.14.2, and that once you do, running nvm use 11 or nvm use 10 will automatically select the latest appropriate version (but you'll still have to manually reinstall any global packages).
This might be an opportunity to take stock of global packages, they often cause more trouble than they are worth. (In general, the fewer global packages installed the better.)
It's unsupported by design
https://github.com/coreybutler/nvm-windows/issues/236
NVM4W provides a more minimalistic approach, focusing on node version
management, not npm management. NVM4W leaves workflow customization to
the end user... because a) it's not hard, and b) it's very
opinionated.
The statement "switching node version needs reinstallation of all
packages in most cases" is unsubstantiated. This doesn't mean it's not
true, but there aren't any stats to back this claim. There are plenty
of use cases where this is not the case, such as developing original
modules with forward/backwards compatibility.
Third, automating this process, either forcibly or by default, has a
number of unintended consequences in a Windows environment. See the
Roaming Profiles use case for an example.
Even if this were a non-default optional command, it still strays from
node version management into npm management. This is an entirely
different problem (and a much bigger problem).
I haven't updated my Node for a very long time. My current version is v.6.12.3
Would there be any bugs if I don't update my Node?
Node 6 has long-term support state until April, 2019.
Node 6.12 is quite stable and has 99% support for ES6, it's acceptable to use it for development. It's recommended to update to latest Node 6 release for security and bug fixes, especially in production.
It's possible that some packages use features that aren't supported by Node 6 or mark it as unsupported in package.json engines, but in fact almost every third-party package still supports it.
NVM (Node version manager) is for managing different versions of node.js. However, since node.js v6 has good backward compatibility with node.js 4, wouldn't it make sense to simply upgrade to v6? Stick to one version. Wouldn't that make life easier? What are some situations when nvm would be useful?
You may have versions in the future that won't be backward compatible, or some of your old client are still running on Node.js version 0.x.x.
Meteor is typically behind in Node.js version because it is a framework that uses its own bundled version of Node.js, and its APIs and features are built to rely on that version of Node.js.
I'm sure that in many cases upgrading Node.js poses no problem.
As an example, Meteor 2.10 at time of writing ships with Node.js 14. But we're already on Node.js 19.
Is there a way to tell Meteor (f.e. with the meteor cli, or some meteor package) to use newer versions of Node.js (and npm)?
Meteor 1.4 now supports Node 4.4.7!
See release notes
To upgrade to Meteor 1.4:
Go to the root of your project's directory
meteor update
Meteor does not support NodeJS 4+ as of now. The discussion is available in https://github.com/meteor/meteor/issues/5124
The latest update to the thread on April 29 is:
Guys, relax. The difference between Node version 4, 5 and 6 are relatively minor, and so if Meteor can support one, it can and will support all others. Ben created PRs for every currently active and supported Node version, but the fundamental part of the work is about making Meteor work with any (recent, non-legacy) Node version, and from there basically everyone should be able to freely select whichever one fits their goals and intentions best (i.e. 4.x if you don't care for bleeding edge Node, 6.x if you do; 5.x is not going to stick around for very long as it's not an LTS version).
So come and check out and help with the PRs if you're interested and
you can, but if not, just rest assured this is being worked on and
prioritized appropriately and I'm pretty sure Ben (and/or others
working on this) will keep everyone posted on any meaningful progress.
when I run
node -v
I got 4.2.1 which is very strange since I remember I worked with 0.10 versions: I am totally lost with nodejs versions
reading the pm2 doc
Warning: If you want to use the embedded load balancer (cluster mode),
we recommend the use of node#0.12.0+ or node#0.11.16+. We do not
support node#0.10.*'s cluster module anymore.
I don't understand how node.js versions works: looks like we jumped form 0.10
to 4.2
Does pm2 works with latest version of node.js ?
regards
don't understand how node.js versions works: looks like we jumped form 0.10 to 4.2
When io.js and node.js merged, then node.js jump directly to 4.x series. This happened due to difference in versions of io.js (3.x series) and node.js (0.x series). So next common version was named 4.x series and this lead to some confusion. See this announcement.
Does pm2 works with latest version of node.js ?
You can give it a try yourself, but IMO it should work well.
At the end of 2014, node was forked into io.js for reasons I won't cover here.
The io.js project adopted the semver notation and, as the pace of changes was very fast (we got all the recent advances of ES6 that were already available in V8), came to version 3.
In september 2015, io.js was merged back into node, and it was decided to keep the semver versionning, and to go to version 4. More details here, including the LTS.
This makes it possible to deal with a monotonous version order, thus a 4.0 version of node is greater than a 0.11 version. But be wary, many changes were introduced and the ecosystem is big. You'll probably have changes to do when going from 0.x to a new version, especially if you use many modules.