[BUG] ETARGET installing package I just published (not invalidating cache?)

[isaacs]

Is there an existing issue for this?

• [X] I have searched the existing issues

This issue exists in the latest npm version

• [X] I am using the latest npm

Current Behavior

Publish libtap 1.3.0 cd to tap try to install [email protected] ETARGET forever, even though npm view libtap version reports 1.3.0

$ npm view libtap version
1.3.0

$ npm i [email protected]
npm ERR! code ETARGET
npm ERR! notarget No matching version found for [email protected].
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/isaacs/.npm/_logs/2022-03-05T19_32_50_810Z-debug-0.log

$ npm -v
8.5.3

Expected Behavior

Should fetch version 1.3.0 from registry

Steps To Reproduce

See description

Environment

• npm: 8.5.3
• Node.js: v17.6.0
• OS Name: Darwin
• System Model Name: Darwin moxy.lan 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan 5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T6000 arm64
• npm config:

; "user" config from /Users/isaacs/.npmrc

@npm:registry = "https://npm.pkg.github.com/" 
//npm.pkg.github.com/:_authToken = (protected) 
//npm.toddself-pkg1.ghaedev.com/:_authToken = (protected) 
//registry.internal.npmjs.com/:_authToken = (protected) 
//registry.npm.red/:_authToken = (protected) 
//registry.npmjs.org/:_authToken = (protected) 
//registry.npmjs.rocks/:_authToken = (protected) 
access = "public" 
foo = "baz" 
script-shell = "bash" 
sign-git-commit = true 
sign-git-tag = true 

; node bin location = /usr/local/bin/node
; cwd = /Users/isaacs/.npm/_logs
; HOME = /Users/isaacs
; Run `npm config ls -l` to show all defaults.

Logs and relevant cache files attached below

2022-03-05T19_35_59_088Z-debug-0.log

npm-view-libtap-version.log

_cacache.zip

[isaacs]

It does eventually seem to work, but only after about 5 minutes or so. So it looks like we're holding onto cache without revalidating it, even though the ETag has changed. Since that's within the "serve from cache without revalidating" window, maybe that's "correct" behavior, but interestingly, npm ls doesn't do that.

I think at least, maybe make-fetch-happen could be smart enough to say "I just did a POST to that url, so let's make sure to always revalidate that cache entry", or something?

[nlf]

we do make efforts to invalidate the cache when a package is published, but npm view being unaffected while npm install is makes it sound like we're possibly invalidating the full packument correctly but not the corgi. we'll look into this one!

[kalinkrustev]

Maybe it is related to this comment: https://github.com/npm/cli/blob/f2340f816f5a137038945229bf8a0d30160e76e8/node_modules/pacote/lib/registry.js#L131

Looks like a todo, which did not happen...

[jsjoeio]

I'm facing this now. We publish each pr for coder/code-server under the package name @coder/code-server-pr and tag it with the PR number. When I run npm install --unsafe-perms @coder/code-server-pr@5673 I get:

npm ERR! code ETARGET
npm ERR! notarget No matching version found for @coder/code-server-pr@5673.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/jp/.npm/_logs/2022-10-20T18_33_28_214Z-debug-0.log

yet when I run npm view @coder/code-server-pr, I see it in the list:

5673: 4.7.1-5673-3c17798eb377432f160f3aef7cad61bb2a26a83f
latest: 4.1.0-4972-4f800181a0de4ee60389f9d90200bb088e7d8a2e

If I use the exact version i.e. npm install @coder/code-server-pr@4.7.1-5673-3c17798eb377432f160f3aef7cad61bb2a26a83f it works.

[original001]

I'm experiencing the same issue. When I publish package to my components library, my CI immediatly fall, because it cannot install versions in updated package.json.

Is there any update of this?

[lionello]

Doing npm install --force … doesn't work, but running npm cache clean --force seems to have purged whatever was keeping it from contacting the registry.

[vangenechtenbert]

Same issue here in npm 10.2.3

[cniweb]

Same issue here in npm v10.2.3 (with node v18.18.1)

[iamrakesh]

We too ran into the same problem since move to NodeJs to 20.x (from NodeJs 14.x). Our CI setup, builds/publishes a NPM package and is consumed by other project in the same build cycle at a later point. We were able to solve/work it around by using 'prefer-online=true' instead of 'prefer-offline=true' in our .npmrc file.

[silverwind]

My experience with this bug:

• If one installs a package within the first ~30s of publish, it always fails with ETARGET. This will then trigger a bad negative cache and in may then fail for up to 5 minutes.
• If one waits around ~60s after publish and the install, it works reliably and does not trigger the bad cache.

The registry API always gives the correct version, making me believe this is a local cache problem in the cli.