[BUG] npx is too slow for already cached package with specific version requested

[jedwards1211]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

I'm npxing a specific version of a package that's already been npxed before.
There is a long delay (at least 3 seconds) even before it fetches the package information from the registry (which, why is this necessary for a specific version that's already installed?) and using --ddd doesn't provide any information why the delay is happening.

$ npx --ddd type-annotation-to-json-schema@1.0.0
npm verb cli /Users/andy/.nvm/versions/node/v21.7.1/bin/node /Users/andy/.nvm/versions/node/v21.7.1/lib/node_modules/npm/bin/npm-cli.js
npm info using npm@10.5.0
npm info using node@v21.7.1
npm verb title npm exec type-annotation-to-json-schema@1.0.0
npm verb argv "exec" "--loglevel" "silly" "--" "type-annotation-to-json-schema@1.0.0"
npm verb logfile logs-max:10 dir:/Users/andy/.npm/_logs/2024-03-18T14_33_12_835Z-
npm verb logfile /Users/andy/.npm/_logs/2024-03-18T14_33_12_835Z-debug-0.log
npm sill logfile start cleaning logs, removing 7 files
npm sill logfile done cleaning log files
**...LONG MYSTERIOUS DELAY...**
npm http fetch GET 200 https://registry.npmjs.org/type-annotation-to-json-schema 460ms (cache revalidated)
type-annotation-to-json-schema <file> <identifier>

Expected Behavior

npx should be virtually instantaneous for a specific version of a package that's already installed. I expected it to not fetch anything from the registry if the package is already in cache.

Steps To Reproduce

1. Run npx --ddd gen-typed-validators@1.0.0 several times
2. Observe long delay before it finishes running even after the first time

Environment

• npm: 10.5.0
• Node.js: 21.7.1
• OS Name: macOS 14.4
• System Model Name: Macbook Pro
• npm config:

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

//registry.npmjs.org/:_authToken = (protected) 
hoist = true 
registry = "https://registry.npmjs.org/" 

; node bin location = /Users/andy/.nvm/versions/node/v21.7.1/bin/node
; node version = v21.7.1
; npm local prefix = /Users/andy/gh/clarity
; npm version = 10.5.0
; cwd = /Users/andy/gh/clarity
; HOME = /Users/andy
; Run `npm config ls -l` to show all defaults.

; "publishConfig" from /Users/andy/gh/clarity/package.json
; This set of config values will be used at publish-time.

access = "restricted"

[milaninfy]

@jedwards1211 I tried multiple times, but not able to reproduce the issue.

[jedwards1211]

@milaninfy one thing you could try is throttling your internet connection

[lukekarrys]

npx is hitting the network to fetch the packument and ensure there is not a newer version to run. This is easiest to see with --loglevel=http:

❯ npx --loglevel=http gen-typed-validators@1.1.5
npm http fetch GET 200 https://registry.npmjs.org/gen-typed-validators 146ms (cache revalidated)
gen-typed-validators <files>
...

This makes sense in the case of npx gen-typed-validators@latest but probably not for npx gen-typed-validators@1.0.0 where a specific version is requested. On my network this "only" took 146ms, but still a decent cost to pay for something we know didn't change.

I also thought that the network request would be skipped if the cache is new enough (10 minutes?), but I haven't dug into the specifics if that's a bug or not.

I think it's reasonable that npx does not hit the network at least in the case of a specific version being requested. For @latest and bare specs, this is a tradeoff as many users have requested that the cache version not be used.

[ljharb]

Anything that could change based on the network - tags and ranges - seem totally reasonable to always make an http call, but fwiw I totally agree that for a specific already-cached version, there's no value in checking.