TLDR: normally lazy loading in this module is a 🚨 warning zone 🚨 but not for this particular code path.

The danger in lazy loading (especially in this file) is when npm is installing over itself. Unless I'm missing something really obscure I can't imagine why this code path would be called during that situation.

Even if we were doing an npm i -g npm, this error would only happen if we got a 404 from the registry. That would only happen on npm itself (because npm bundles all of its dependencies) meaning that we'd be aborting long before we removed the existing global npm package.

$ npm i -g npm@latest --loglevel verbose
npm verb cli /Users/wraithgar/.nvm/versions/node/v20.10.0/bin/node /Users/wraithgar/.nvm/versions/node/v20.10.0/bin/npm
npm info using npm@10.5.1
npm info using node@v20.10.0
npm verb title npm i npm@latest
npm verb argv "i" "--global" "npm@latest" "--loglevel" "verbose"
npm verb logfile logs-max:10 dir:/Users/wraithgar/.npm/_logs/2024-04-06T18_08_01_736Z-
npm verb logfile /Users/wraithgar/.npm/_logs/2024-04-06T18_08_01_736Z-debug-0.log
npm http fetch GET 200 https://registry.npmjs.org/npm 234ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/npm 11ms (cache hit)

changed 14 packages in 12s
npm verb exit 0
npm info ok 

@H4ad chore is only for things that won't affect the published module. Refresher on our conventional commit approach here: https://github.com/npm/cli/blob/latest/CONTRIBUTING.md#pull-request-conventions

Approved but I'm gonna ask @lukekarrys to either merge or 👍 for a sensibility check since this is dealing w/ lazy loading and we should be extra cautious.