# NPM Proxy Cache Issues

**URL:** https://community.sonatype.com/t/npm-proxy-cache-issues/12068
**Category:** Sonatype Nexus Repository
**Tags:** nexus-repository, npm
**Created:** [February 12, 2024, 8:08pm UTC](https://community.sonatype.com/t/npm-proxy-cache-issues/12068 "2024-02-12T20:08:43Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![david.welch](https://avatars.discourse-cdn.com/v4/letter/d/8491ac/32.png) [@david.welch](https://community.sonatype.com/u/david.welch)
#### Post date: [February 12, 2024, 8:08pm UTC](https://community.sonatype.com/t/npm-proxy-cache-issues/12068/1 "2024-02-12T20:08:43Z")

</div>

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:  
[https://www.npmjs.com/package/@humanwhocodes/config-array?activeTab=code](https://www.npmjs.com/package/@humanwhocodes/config-array?activeTab=code)  
[https://www.npmjs.com/package/@aws-sdk/client-s3?activeTab=code](https://www.npmjs.com/package/@aws-sdk/client-s3?activeTab=code)

---

<div class="post-metadata">

### Author: ![mpiggott](https://avatars.discourse-cdn.com/v4/letter/m/f0a364/32.png) [@mpiggott](https://community.sonatype.com/u/mpiggott)
#### Post date: [February 12, 2024, 8:19pm UTC](https://community.sonatype.com/t/npm-proxy-cache-issues/12068/2 "2024-02-12T20:19:45Z")

</div>

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

---

<div class="post-metadata">

### Author: ![david.welch](https://avatars.discourse-cdn.com/v4/letter/d/8491ac/32.png) [@david.welch](https://community.sonatype.com/u/david.welch)
#### Post date: [February 13, 2024, 3:16pm UTC](https://community.sonatype.com/t/npm-proxy-cache-issues/12068/3 "2024-02-13T15:16:34Z")

</div>

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