npm install gets stuck at fetchMetadata

You can try by setting the configuration to:

npm config set registry

It works for me

This is how I resolved this after spending half an hour:

1. `npm config set registry

[To see links please register here]

--global`
2. `npm cache clear --force`
3. setting package-lock.json to `{}` only
4. `npm install --verbose`

node: v12.14.1
npm: v6.13.4

This issue occure when I tried running `ng update` on angular 6 app to update it to angular 9.

May be you are sitting behind a corporation firewall which uses proxy everywhere. Depending on your situation, you may to modify local .npmrc for your current project instead of the global one that affects all npm commands on your computer.

You can equivalently set the configuration properties using commands of the form "npm config set <key> <value>", e.g. npm config set registry

[To see links please register here]

**Execute below commands on terminal:-**

npm config set registry <CORPORATE_ARTIFACTORY>

npm config set https-proxy null

npm config set proxy null

I resolved my issue using this:

```
npm cache clear --force
```

and then setting the max websockets lower than the default 50

```
npm set maxsockets 3
```

I think this implies that for me the issue was a very slow install rather than a truly stuck one, but this might help some people.

One of the possible reasons of this is that you have a problematic circular dependency.

In my case I had two packages fetched directly from Github, and they both had the other as their dependency. As a result, on a 'fetch metadata' phase, when npm clones such packages into npm cache directory, they triggered 'git clone' of each other in an endless loop.
Before I has a chance to understand what's happening, npm cache directory grew to an enormous size like 50Gb or so.

Additional gotcha is that it is hard to tell what package causes problem because npm logging in not precise enough and npm install process may seem to stuck on completely different package. In this case check your npm cache directory (~/.npm/_cacache/tmp) to see what repositories are repeatedly cloned.

P.S. I encountered this problem with npm6, but it seems like npm7 treats this case differently and everything is working fine.

Hopefully this will help someone to save time and nerves.

I had the same problem with, in my case I cloned one project and I used the following commands in the command prompt in order to run it:

```
yarn install
cd {Project_name}
npm install
nx serve
```
Hope that this will help!

`npm ci` did resolve that for me (today).
Afterwards `npm install` seems to be working fine again.

I think this can be caused by many reasons but with npm not telling us, we all have to use guesswork. In my case on Windows, I use Putty's Plink as the Git SSH client. When trying to fix an unrelated bug, I cleared the Putty known host registry.

Some of my node modules are on Github so when npm was trying to use git to install them, Plink was asking me did I trust Github.com. For some reason npm didn't output this to me. You can easily verify if this is your problem by trying to do any fetch/pull on any Github.com repo and you'll see the Plink `the server's host key is not cached in the registry` message. Just press y to trust Github (or load Github.com in the Putty GUI) and it all worked for me.

I really doubt there's many people who had the same problem as me but I might as well post my fix.

For me it worked when I changed(set) registry.

npm set registry yourcompanydomainregistry.com

OR

go to `.npmrc` file and set/change registry there.

registry=yourcompanydomainregistry.com

I have also fell into it.
The symptom: hanging up with Checking installable status.
The CPU usage was ~3%, the memory allocation was a bit up and down ~5Mb, and no network traffic, hdd write / read (as a normal package manager tries to resolve conflicts in dependencies)

After trying npm cache clear --force, etc... did not helped.
Started to install the packages manually, and after a dozen packages, it was 2 different version from the same package, which were conflicting.

The solution was to replace a dependency from github link (no tagging / commit lock) to a package link.
After that, it was going well.