NPM Proxy Cache Issues

Sonatype Nexus Repository
,
1

We are seeing an issue that I believe is a result of the way that Nexus’ NPM Proxy handles the cache settings for maximum component age and maximum metadata age. Intermittently we are seeing failures of NPM install due to NPM being unable to find a version of the requested package. The best example that we have of this is @humanwhocodes/object-schema, it appears that what is happening is our dependency on @humanwhocodes/config-array defines the exact version to be used in the package.json file under “dependencies”.

So for example, a request of the object-schema package is made re-setting the 24 hour timer for the proxy maximum age settings on that package. Then later, but within that 24 hour window a request is made of config-array which points to the newest version of object-schema that our proxy cache is unaware of. We are then getting this error message.

exec error: Error: Command failed: xcopy /eyi node_modules@my-name\my-name-common ...\MyNameCommon\ && xcopy /eyi .npmrc ...\MyNameCommon\ && cd ...\MyNameCommon && npm cache clean --force && npm install
npm ERR! code ETARGET
npm ERR! notarget No matching version found for @humanwhocodes/object-schema@^2.0.2.

These types of failures have been happening intermittently in our environment for years. Another instance of this recently happened with @aws-sdk/middleware-expect-continue which is a dependency of the @aws-sdk/client-s3 package.

Links:

1 Like
2

To me this sounds like your users are not using metadata provided by Nexus locally and are instead resolving dependencies directly against npmjs?

3

“I’m not sure what you mean, it appears that the config-array package is returning an hard coded version for the object-schema package, but (I assume) because the object-schema package is still within the maximum age cache settings, it doesn’t reach out to NPMJS to check that package.”