Npm _cacache Gotcha!

Having deleted my npm-proxy repository and my Jenkins project workspace, I was surprised that when I re-ran my Jenkins job to ‘npm install’ JuiceShop, that the components were not uploaded to my new replacement npm-proxy repository.

They were however uploaded to a new repository with a different name (for which I had enabled quarantining) when I scanned from the command line. In order to successfully complete the ‘npm install’ I had to waive the Firewall policy enforcements I had configured.

I then deleted the components that failed Firewall policy from the repo and the project node_modules cache directory. I rescinded those waivers, with the expectation that policy enforcement would kick in once more and I would see failures on account of Firewall. Not so!

After a quick prayer to the god of Google, I have learned that npm creates a ~/.npm/_cacache directory. This saves the need to pull the components from the Internet, thus preventing the expected policy failures from being observed once more.

In order to clear this cache and thus restore the expected behaviour described above, you must issue the following command:

npm cache clean --force

My subsequent ‘npm install’ failed as expected on account of Firewall being active.


Nice sleuthing!

Maven (~/.m2/repository) and NuGet (~/.nuget/package on macos) do this and I’m sure PyPi, RubyGems, and Docker.

It’s always my assumption that these tools have some sort of local cache. If I’m unsure, I’ll tail -f request.log to watch what traffic is actually hitting my NXRM server.

You also have to pay attention to the payload size that’s being transmitted. I believe npm is notorious of this where it’ll check the Repo for updated metadata, so you’ll see some repo traffic, but then actually serve the package from local cache.

1 Like

The article that describes the cache:

1 Like