NPM Proxy Cache Issues

post by david.welch on Feb 12, 2024

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.

post by mpiggott on Feb 12, 2024

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

post by david.welch on Feb 13, 2024

“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.”