npm retry behavior may cause duplicate package writes—how can this be prevented without disabling retries?

Direct answer

No. npm can stop retrying failed registry fetches by setting fetch-retries to 0, but that does not make install scripts idempotent, isolate their side effects from retries, or repair an already inconsistent package-lock.json. Duplicate writes usually come from re-running the install after a partial failure or from non-idempotent lifecycle scripts, not from npm retrying a single fetch.

Likely explanation versus confirmed facts

Likely explanation

When a registry tarball fetch fails, npm retries the fetch itself. It does not normally re-run preinstall, install, or postinstall on every retry. If you see duplicate entries or repeated side effects, the more probable causes are:

• An external wrapper, CI job, or developer re-runs npm install after the first attempt fails partway through.
• A lifecycle script writes files before the network error and runs again when the whole install is re-invoked.
• An interrupted write leaves node_modules and package-lock.json out of sync.

Confirmed facts

• npm exposes fetch-retries, fetch-retry-mintimeout, fetch-retry-maxtimeout, and fetch-retry-factor. Defaults vary by npm major version.
• npm ci requires package.json and package-lock.json to be synchronized; it fails rather than repairing a drifted lockfile.
• Setting fetch-retries to 0 makes the first failed fetch fail the install immediately. It increases fail-fast behavior but does not fix existing corruption.

Steps for this case

1. Check the current retry setting:

   npm config get fetch-retries

2. Test fail-fast behavior on a clean copy:

   npm install --fetch-retries 0

3. If duplicates still appear after one command, inspect preinstall, install, and postinstall in package.json. Guard file writes with a sentinel file or existence check so the script is idempotent.
4. In CI, prefer npm ci from a committed lockfile. If the lockfile is corrupted, regenerate it from a known-good commit rather than editing it by hand.

Missing diagnostic detail

Do the duplicates appear after a single npm install completes, or only when something re-runs the command after a failure? This determines whether to adjust fetch-retries or fix the external wrapper and lifecycle scripts.

Assumptions and uncertainty

This answer assumes a recent npm major version (npm 6 or later). Config names and default retry counts can differ in older versions; verify with npm config get fetch-retries. It is not confirmed that npm re-runs lifecycle scripts on every fetch retry; treat that as unverified and check your own install output if the problem persists.

Verification

• Run npm config get fetch-retries before and after npm install --fetch-retries 0 to confirm the flag applies.
• After a controlled failure, inspect git diff -- package-lock.json and check whether script-generated files appear more than once.
• Re-run the install script manually after adding a guard to confirm no duplicate side effects.