130

What am I doing wrong when setting up my packages ? Is there any way to speed this up ?

  • packages.json :

    { "name": "testing node", "version": "0.0.0", "description": "", "main": "app.config.js", "dependencies": { "babel-core": "^6.17.0", "babel-loader": "^6.2.0", "babel-plugin-add-module-exports": "^0.1.2", "babel-plugin-react-html-attrs": "^2.0.0", "babel-plugin-transform-class-properties": "^6.3.13", "babel-plugin-transform-decorators-legacy": "^1.3.4", "babel-preset-es2015": "^6.3.13", "babel-preset-react": "^6.3.13", "babel-preset-stage-0": "^6.3.13", "react": "^0.14.6", "react-dom": "^0.14.6", "webpack": "^1.12.9", "webpack-dev-server": "^1.14.1", "mysql": "*" }, "devDependencies": {}, "scripts": { "dev": "webpack-dev-server --content-base src --inline --hot", "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC" }

When inside the folder if I run

npm install

I get the following which can take hours to fully setup:

npm install stuck

This is not a general computing or hardware issue. Comparative speeds are below :

    1. Run haversine to calculate all distances on over 1 million records in a non-index mysql table takes significantly less time. (computational)
    1. Download a full install of Linux (Dual Layer DVD ISO) in significantly less time. (bandwidth)

I suspect there is something wrong with my packages.json or the command I am running npm install. From the image, it seems there are numerous attempts to retrieve the same file. Possibly there is a way to force npm to retrieve from a more stable mirror ? Possible the mirror selection it uses by default is wonky ? Just some suggestions -- I don't know the specific cause which is why I am asking.

This problem also occurs on my Linode, Digital Ocean, and VULTR boxes -- so I suspect it is something specific with npm, the way I am using (something missing), or my packages.json.

Improve this question
20
  • Is there any more meaningful output when you do npm --loglevel=silly install? Commented Jan 7, 2017 at 18:27
  • 13
    @hardillb - not really a problem with my internet or machine speed. Can download a full install of linux faster than npm install takes to grab a few scripts -- on the same computer. Comparitively, can run haversine on a non-index recordset in mysql over 1 million records faster. Commented Jan 7, 2017 at 18:30
  • 1
    "I suspect there is something wrong with my packages.json or the command I am running npm install" - I don't think so. I installed modules here in less than 1 min with your package.json with npm v3.5.2 and node v4.2.6. I suggest you update node and npm. Commented Jan 7, 2017 at 19:09
  • 10
    That is a very, very old version of npm. I wouldn't be surprised if this is a bug in npm that was fixed in a later version. Can you update your npm to latest? sudo npm install -g npm@latest Commented Jan 7, 2017 at 19:11
  • 1
    Generally speaking, don't rely on package managers like apt to maintain up-to-date software. I would strongly recommend purging the node/npm combo you installed from apt and following the instructions on nodejs.org to install the latest release. Commented Jan 7, 2017 at 19:54

15 Answers 15

Reset to default
72

I was able to resolve this from the comments section; outlining the process below.

From the comments

AndreFigueiredo stated :

I installed modules here in less than 1 min with your package.json with npm v3.5.2 and node v4.2.6. I suggest you update node and npm.

v1.3.0 didn't even have flattened dependencies introduced on v3 that resolved a lot of annoying issues

LINKIWI stated :

Generally speaking, don't rely on package managers like apt to maintain up-to-date software. I would strongly recommend purging the node/npm combo you installed from apt and following the instructions on nodejs.org to install the latest release.

Observations

Following their advice, I noticed that CentOS, Ubuntu, and Debian all use very outdated versions of nodejs and npm when retrieving the current version using apt or yum (depending on operating systems primary package manager).

Get rid of the outdated nodejs and npm

To resolve this with as minimal headache as possible, I ran the following command (on Ubuntu) :

apt-get purge --auto-remove nodejs npm

This purged the system of the archaic nodejs and npm as well as all dependencies which were no longer required

Install current nodejs and compatible npm

The next objective was to get a current version of both nodejs and npm which I can snag nodejs directly from here and either compile or use the binary, however this would not make it easy to swap versions as I need to (depending on age of project).

I came across a great package called nvm which (so far) seems to manage this task quite well. To install the current stable latest build of version 7 of nodejs :

Install nvm

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh | bash

Source .bashrc

source ~/.bashrc

Use nvm to install nodejs 7.x

nvm install 7

After installation I was pleasantly surprised by much faster performance of npm, that it also now showed a pretty progress bar while snagging packages.

For those curious, the current (as of this date) version of npm should look like the following (and if it doesn't, you likely need to update it):

current npm running

Summary

DO NOT USE YOUR OS PACKAGE MANAGER TO INSTALL NODE.JS OR NPM - You will get very bad results as it seems no OS is keeping these packages (not even close to) current. If you find that npm is running slow and it isn't your computer or internet, it is most likely because of a severely outdated version.

Improve this answer
Sign up to request clarification or add additional context in comments.

9 Comments

Nice. n is worth considering as a simpler alternative to nvm, installable with curl -L https://git.io/n-install | bash
I strongly recommend using nvm to tune which version of node you are running. github.com/creationix/nvm
For current releases one can just add a repo, as specified on the Node.js site
I concur with nvm recommendation, especially with the --lts flag, which will keep you updated to the latest "long-term support" release of npm, which should be both current, and stable.
Pipe shell script from internet to bash is not good thing to do.
|
17

I am using Linux and have nvm and working with more than 7 version of node As of my experience I experienced the same situation with my latest project (actually not hours but minutes as I can't wait hours because of hourly project :))

Disclaimer: don't try below option until you know how cache clean works

npm cache clean --force

and then all working fine for me so it's looks like sometimes npm's cache gets confused with different versions of Node.

Official documentation of Npm cache can be found here

Improve this answer

3 Comments

I was having issues with the initial "loading" of npm. The first message would stay up for a good 15-30 seconds and then it would blaze by. After running your command, it fixed the issue! Now it starts right away like usual nodejs v8.11.3 and npm 5.6.0 on Windows 7 x64
I think adding a brief explanation about how cache clean works (or at least a link) would be better here
The npm cache is now considered as very stable. Also, I can't imagine how deleting and therefore re-downloading cached data is supposed to speed up npm in any way at all.
13

I see from your screenshot that you are using WSL on Windows. And, with Windows, comes virus scanners, and virus scanning can make NPM install very slow!

Adding an exemption or disabling virus scanning during install can greatly speed it up, but potentially this is undesirable given the possibility of malicious NPM packages

One link suggests triple install time https://ikriv.com/blog/?p=2174

I have not profiled extensively myself though

Improve this answer

2 Comments

I can confirm that disabling the real-time scanning does increase the speed of npm install.
This is a very overlooked problem, good for you to put it here. Thanks.
5

I was having this problem and none of the solutions in SO helped. I figured it out so I am posting it here in case any one else has a similar issue.

I was trying to run npm i on an amazon instance. The problem ended up being the fact that linux only opens up a certain amount of ports, and when npm i runs, it opens like more than a thousand connects to the registry to download all the packages. So it would work but then just freeze for like 15 minutes. Then the timeout would occur and it would eventually move on to another port. So in my security group in AWS I added a rule for All TCP at 0.0.0.0/0 in outgoing only, letting npm open as many outgoing connections as it likes and that fixed it.

Improve this answer

1 Comment

How did you do this?
4

Problem: NPM does not perform well if you do not keep it up to date. However, bleeding edge versions have been broken for me in the past.

Solution: As Kraang mentioned, use node version manager nvm, with its --lts flag

Install it:

curl -o- https://raw.githubusercontent.com/creationix/nvm/master/install.sh | bash

Then use this often to upgrade to the latest "long-term support" version of NPM:

nvm install --lts

Big caveat: you'll likely have to reinstall all packages when you get a new npm version.

Improve this answer

Comments

2

I was having the same problem, i am on the nodejs version: 8.9.4 and npm version: 5.6.0. I tried a lot solutions online, including the ones on this post, none worked for me, then i found about yarn package manager which solved the problem for me, so if all fails, i think "yarn" is worth checking out.

EDIT:

It seems npm has problems when it is outdated, updating it has helped me as well.

Improve this answer

Comments

2

I had the same problem on Debian, yarn was the solution for me.

Improve this answer

Comments

1

This link helped me boost npm installs. Force npm to use http over https and disable progress display.

Improve this answer

Comments

1

we also have had similar problems (we're behind a corporate proxy). changing to yarn at least on our jenkins builds made a huge difference.

there are some minor differences in the results between "npm install" and "yarn install" - but nothing that hurts us.

Improve this answer

Comments

1

Piggybacking on @Colin D's answer about virus scanners and Windows boxes.

There's one more element of Windows that causes NPM to be slow as well. Windows is notoriously heavy when downloading files in general, this is normally not noticed because most of the time we are downloading a single file or zip of files and so we are only downloading from a single source and file.

With npm we are downloading 1000s of files that can get easily into the GBs total download. The way this was described to me in the past, and might be a bit too simplistic, but it made it make sense to me is: Each file that Windows downloads is wrapped in whatever network protocol is being used (TCP) and then run through Windows networking. Usually is negligible, but in the case of these tiny 1kb files it explodes.

Wish I had a more official source for you, so if anyone can help me provide one I'd be grateful. Best I found was this: https://with.raidrive.com/t/very-slow-download-speed-with-small-files/3423/4

For me I'm the source, as we ran into this problem a long time ago when we used to run SVN. It was super slow and we found it was the combination of the network packets and the virus scanner.

Hope this helps.

Improve this answer

Comments

0

I had similar problems. I was also confused by some solutions leaving me with different versions displaying for different users. If you have any problems at all, I would first check every account your using any implementation of node

Finally, this solution appears to solve this issue 100%, giving me the confidence that my versions were universal no matter what user privileges I wanted to use:

 sudo yum update sudo yum install build-essential checkinstall libssl-dev curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.35.1/install.sh | bash (sudo) nvm --version (sudo) nvm ls-remote (sudo) nvm install [version.number]

1

If you're still having a problem, next try looking inside your /usr/local/bin directory. If you find either a large binary document named node or a folder named npm, delete them.

 rm /usr/local/bin/node rm -r /usr/local/bin/npm

Personally, before I deleted those, two of my user accounts were using the latest version of node/npm installed correctly via nvm, while a third account of mine remained stubborn by still using a far older installation of both node and npm apparently located inside my /usr/local/bin/ directory. As soon as I deleted both of them with the two above commands, that problematic user account implicitly began running the correct installation, having all three accounts mutually the intended versions.

(Implemented while using Centos 7 Blank x64. Some source code used above was originally supplied by 'phoenixNAP Global IT services' 1)

Improve this answer

Comments

0

This didn't work well for me (didn't remove everything):

npm cache clean --force

but this did solve my issue:

rm -rf ~/.npm/
Improve this answer

1 Comment

what is this supposed to do? delete npm directory content globally?
0

In my case my company VPN was blocking required calls. As soon as I disconnected it started working just fine.

Improve this answer

1 Comment

Inversely, if your npmrc is set to your company's internal registry, you may be to reconnect VPN :)
0

I'd like to add a possible solution to this. In my case, I had issues in the past where IPV6 requests would take forever to finally fail, I had to disable IPV6 in curl for example. Probably an issue with my ISP. This is why my internet connection appeared to work as fast as ever while some other stuff failed, the stuff that prioritizes IPV6. So I ran this and problem fixed:

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1
Improve this answer

4 Comments

worked for me, thanks
If you have issues with IPv6, fix your connection, make sure software developers fix their software and add happy eyeballs support NEVER disabled the current generation of the IP protocol.
After looking into it, it's 100% an ISP problem. But if I call to my ISP they don't even know what "upload speed" means, I'd rather not waste time on that. I just shared a workaround, if that's appropriate for anyone's situation.
If a ping over IPv6 fails you have a routing issue, ’ip -6 r’ will give you the routing table, you can then use ’ip nei’ to find the Mac address and then verify why device it is. If it is a ISP provided device that you can't change, then sure. But it is often some other device, such as a pihole that tries to be smart. If however it is slow, or failing with bigger packets, you might have a broken nic that fails to do v6 checksum offload incorrectly, you can disable that and it will work, this is not your ISPs fault ;)
-3

One thing I noticed is, if you are working in new project(folder) you have to reconfigure proxy setting for the particular path

  1. Cd(change terminal window path to the destination folder.

  2. npm config set proxy http://(ip address):(port)

  3. npm config set https-proxy http://(ip address):(port)

  4. npm install -g @angular/cli

Improve this answer

1 Comment

You should not be setting project specific configuration for global script installations. That configuration would also be distributed with the project's package.json file.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.