I have upgraded one nodejs installation from 0.4.2 to 0.8.12 but, since then, the js server I have, started crashing with seg fault. As I inherited this application, I have no idea what was previously installed and how was it was maintained. Npm seems to be installed only locally, but I can't seem to call it the right way.
So this is all the info about the problem. My question is:
Can I completely remove nodejs and npm so I can do a fresh install?
A better approach would be to install nvm .
https://github.com/creationix/nvm
Use nvm to install different versions of node . Then try different versions , say 0.5 then 0.6 and
checkout at which version does the app actually break.
And then refer to the critical changes made in that version and modify your code accordingly.
This would be a good software practice .
Related
I am quite new to NodeJS and am planning to upgrade NodeJS version for my current project. The most recent NodeJS LTS is installed using NVM.
I need to keep switching between the current LTS that i am using and the new LTS that has been installed. I understand that i can do 'NVM use' for this purpose. npm-shrinkwrap.json is being used to lock down the npm package dependencies.
I am planning to follow the below approach both in my dev machine and build machine;
Is it okay? If not, please suggest a best approach.
nvm use latest_LTS
Update the package.json to pick the version which is supported by
latest_LTS
npm install
generate testing_build
Whenever i need to generate a build for current release (with the previous LTS NodeJS)
nvm use currently_used_LTS
clear the node modules
npm install (Release npm-shrinkwrap.json)
generate release_build
Thanks
In theory that should work.
However have you considered the option of just doing a point release for the current release_build that does nothing except version-bump node?
You may find (after re-running your tests) that the latest version of node is backwards compatable with release_build (or only requires minor fixes), and you can simplify your life by porting everything to the latest node version, rather than constantly switching
tl;dr
Is there is a reason that I shouldn't do the following; Install and manage packages with a version of npm that is different (much newer) from the npm version that comes with the node version I am going to be using to run my app.
longer
Some context why I am asking. I have to work with a service that supports only node 0.10.32 (I know, don't ask) and an app that was written some time ago. We need to add some functionality and unfortunately when I try to run the codebase locally it does not because some dependency of some dependency updated the minor version and they introduced const or fat arrow notation (=>). We had used shrinkwrap to lock down the versions but something must have slipped.
I have spent days on this and at some point it came to me that the problem lies with the package manager not doing what I want. So I managed to install the packages I wanted and shrinkwrapped it using npm#3.10.10 which is what I get when I use node#6.12.3 (nvm use 6.12.3). And when I want to run the app I just switch to the node#0.10.32 to make sure that is going to work on the service.
Can anyone think of any problems with this solution or a reason I shouldn't do that?
Side question
I noticed that when installing node versions using nvm, they usually come with a specific version of npm? What is the relation of those versions? How are they decided? Was it the latest npm version along with that node version when it was released? Is it the latest version of npm that can run with that specific version of node?
I installed Node JS several months ago and played around a bit. Today, I wanted to start learning more about node and before coding, I decided I wanted to make sure I had the latest version.
I checked the version and it was something like v0.10.3x. I looked on the NodeJS website and it shows the latest version as v4.1.0. So I thought Woahhh! I better upgrade and I couldn't believe it moved that fast to a 4.x version in only a few months.
I spent quite some time trying to figure out how to completely uninstall node and npm because I couldn't seem to upgrade it.
Finally I got it all ripped out, then installed in on CentOS 7 using yum. I know I won't get the latest version through yum but, I figured it would be close enough.
After install, I am at v0.10.40.
I have a feeling I just don't understand something about NodeJS version numbers.
Yeah if you only used the official node.js runtime then it would have appeared to jump from 0.12.x all the way to 4.0.0 in one fell swoop. What you may not have known was that node devs that were sick of how much the node repository was stagnating made a fork of the project and called it io.js. Under the io.js name the project marched forward over the last six months or so; it started at v1.x and iterated all the way through 2.x and 3.x in that time. Old node.js used a different versioning system wherein the odd versions were unstable and even versions were stable. Io.js switched to using semver versioning semantics like packages on npm already use.
After a lot of deliberation Joyent (original maintainers of node.js) finally caved in and helped form a proper open committee around node in an effort to push the project forward in much the same way io.js was already doing. A few months ago they agreed to merge io.js back into node.js (which was the goal of those who created io.js in the first place). They finally finished merging the two projects recently. The name io.js is no more and node.js lives on starting at v4.0. It will continue to use semver semantics like io.js did :)
Going forward things with node will be MUCH simpler. I'm excited to see where the project goes from here.
That is because since v4.0, the Node.js project and the io.js project that are now combined.
As for the io.js project, the version numbers were like v3.x, v2.x and v1.x.
Reference https://nodejs.org/en/blog/release/v4.0.0/
You can use NVM(Node Versioning manager) for avoiding confusion.
Benefit of this package is you can switch b/w two versions according to your convenient. Its a very easy to use tool.
https://www.liquidweb.com/kb/how-to-install-nvm-node-version-manager-for-node-js-on-ubuntu-12-04-lts/
if you use npm you can upgrade with
sudo npm cache clean -f
sudo npm install -g n
sudo n stable
once done try node -v to see what you got
see more at http://davidwalsh.name/upgrade-nodejs
You can update node or npm using command line. You need to have a version of node or npm installed in your machine.
Use the following command in you terminal.
npm install node -g
npm install npm
You can also install the specific version of node, Like this.
npm install node#8.1.3
npm install npm#4.1.2
Here 8.1.3 is a version number. Use any of the version you want to install.
I installed Node JS several months ago and played around a bit. Today, I wanted to start learning more about node and before coding, I decided I wanted to make sure I had the latest version.
I checked the version and it was something like v0.10.3x. I looked on the NodeJS website and it shows the latest version as v4.1.0. So I thought Woahhh! I better upgrade and I couldn't believe it moved that fast to a 4.x version in only a few months.
I spent quite some time trying to figure out how to completely uninstall node and npm because I couldn't seem to upgrade it.
Finally I got it all ripped out, then installed in on CentOS 7 using yum. I know I won't get the latest version through yum but, I figured it would be close enough.
After install, I am at v0.10.40.
I have a feeling I just don't understand something about NodeJS version numbers.
Yeah if you only used the official node.js runtime then it would have appeared to jump from 0.12.x all the way to 4.0.0 in one fell swoop. What you may not have known was that node devs that were sick of how much the node repository was stagnating made a fork of the project and called it io.js. Under the io.js name the project marched forward over the last six months or so; it started at v1.x and iterated all the way through 2.x and 3.x in that time. Old node.js used a different versioning system wherein the odd versions were unstable and even versions were stable. Io.js switched to using semver versioning semantics like packages on npm already use.
After a lot of deliberation Joyent (original maintainers of node.js) finally caved in and helped form a proper open committee around node in an effort to push the project forward in much the same way io.js was already doing. A few months ago they agreed to merge io.js back into node.js (which was the goal of those who created io.js in the first place). They finally finished merging the two projects recently. The name io.js is no more and node.js lives on starting at v4.0. It will continue to use semver semantics like io.js did :)
Going forward things with node will be MUCH simpler. I'm excited to see where the project goes from here.
That is because since v4.0, the Node.js project and the io.js project that are now combined.
As for the io.js project, the version numbers were like v3.x, v2.x and v1.x.
Reference https://nodejs.org/en/blog/release/v4.0.0/
You can use NVM(Node Versioning manager) for avoiding confusion.
Benefit of this package is you can switch b/w two versions according to your convenient. Its a very easy to use tool.
https://www.liquidweb.com/kb/how-to-install-nvm-node-version-manager-for-node-js-on-ubuntu-12-04-lts/
if you use npm you can upgrade with
sudo npm cache clean -f
sudo npm install -g n
sudo n stable
once done try node -v to see what you got
see more at http://davidwalsh.name/upgrade-nodejs
You can update node or npm using command line. You need to have a version of node or npm installed in your machine.
Use the following command in you terminal.
npm install node -g
npm install npm
You can also install the specific version of node, Like this.
npm install node#8.1.3
npm install npm#4.1.2
Here 8.1.3 is a version number. Use any of the version you want to install.
I already have Node.js v0.8.0 running on Windows. Can I just run the latest installer to upgrade it to v0.8.4? I am afraid it will break existing third party modules on my machine.
Yes, you just install the latest version. Generally you shouldn't have any compatibility problems if you are already using the same major version (e.g. Version 0.8.x). If you are concerned about changes, you can always check the changelog for each version (link to changelog is on node.js download page at nodejs.org). That should tell you of any big changes (i.e API changes, etc).
For the record, I have just gone through the process, and it is painless even if you upgrade to another major version.
I have moved from 0.8 to 0.10, using the .msi package, overwriting the one installed on my system. Package problems were all fixed with npm update -g. Worked like a charm.
In case it does not work like a charm:
npm cache clean usually fixes the problem. Once the cache is empty, just run npm update -g again.
In case you really run into trouble:
Delete the modules you have installed globally, then reinstall them. Here's how:
Take stock of what you have:
npm list -g --depth=0 lists all top-level packages, with version numbers.
npm list -g --parseable --depth=0 > npm-global-modules.txt writes them to a file in your cwd.
Any strange stuff you didn't install yourself has probably been installed by another module (rare, but I have seen it happen). Remove those modules from the list. Also remove the module "npm".
In an editor, format the output for the command line by replacing \n?[^\n]+[\\/] (regex) with a single space.
(I didn't get this to work with findstr in a pipe, hence the roundtrip to the editor. You can also do it manually, of course ;)
Delete all modules. On Windows, delete (or rename) the %appdata%\npm directory. For other OS, see Command to remove all npm modules globally?
Reinstall the modules with npm install -g [your module list here]. Don't forget to npm cache clean before you do it.
I don't have experience with node on Windows, but I have just upgraded node & modules on my Mac, so this is just a general answer:
If you install v0.8, you might break your existing node modules, if they use deprecated functions, etc. The problem is that npm only checks your version of node while modules are being installed, not at run-time.
To be on the safe side, you need to find the global node_modules folder on your machine, back it up to somewhere, then delete and reinstall the modules. You will need to do the same thing for the node_modules folders in the apps you are using. (Assuming you have package.json files, reinstalling these should be easy.)
In practice, I don't think any of the modules I was using were actually incompatible. Good luck.
Yes. You can upgrade your node.js version to the latest by running the installer for latest node.js version at https://nodejs.org/en/. I upgraded mine from 4.4.4 to 8.11.2 running the installer.
Unless you're using a module that relies on an actual bug that was present in 0.8.0 and was fixed by 0.8.4, you're OK. There were no API changes in between those two versions (and the node team is too smart to introduce such changes in a minor release).
Currently upgrading to 4.4.*. I just used to installer from the nodejs.org website and that upgraded everything works just fine.
Just go to nodejs site & download it. You can install it directly without any hesitation. If you have any dependency on earlier version then check change logs.
JUST GO TO
nodejs.org
INSTALL THE LATEST STABLE VERSION (Recommended For Most Users)
and then run
npm install node
Now, you are good to go
You can even check the version of NodeJS using command
node --version
Best way to install node on windows is by using nvm-windows, so you can quickly switch between versions if you need to. This is analogous to the best way of installing node on linux and max, ie with nvm.
But Benjen is right (how could he not be with all his scouting experience) that you can just install a different version of node, and your version will update. Your npm dependencies may have to be reinstalled, and any extensions that aren't managed by npm may need to be recompiled, but this will be true no matter how you change your node version.