npm ERR! code ETARGET

Q: How do I prevent npm:ETARGET in CI?

Keep registry config and auth in `.npmrc` under version control (where appropriate). Pin versions (or use lockfiles) to avoid unexpected tag/range changes. Prefer a proxy/cache registry for CI stability.

Q: How can I manually validate npm:ETARGET?

Check which registry npm is using: `npm config get registry`. If the package is scoped, verify scope registry mapping in `.npmrc` (example: `@your-scope:registry=...`). Query the registry directly for metadata: `npm view @ --json`.

Fix it fast

Most likely: The requested package version, range, or dist-tag does not exist in the registry npm is using.

1. Confirm this is your error

npm ERR! code ETARGET
npm ERR! notarget No matching version found

2. Check the cause

npm config get registry
npm config get @your-scope:registry
npm view <package> versions --json
npm view <package> dist-tags --json
npm view <package>@<requested-version> --json

3. Apply the safe fix

# Choose a version or tag that actually exists in the active registry.
npm install <package>@<published-version>

# If this is a scoped/private package, fix the scope registry mapping before retrying.
npm config get @your-scope:registry

4. Verify it works

npm view <package>@<published-version> --json
npm install

Don't use unsafe shortcuts

Do not delete the lockfile before checking whether the requested version exists.
Do not assume the public npm registry has a private or scoped package.
Do not use a version-like dist-tag unless it is actually listed by the registry.

What npm Could Not Find

npm returned ETARGET because no published version matches the version range or dist-tag requested in your install command.

Check the exact package name, version, and source

Check which registry npm is using with npm config get registry, if the package is scoped, verify scope registry mapping in .npmrc (example: @your-scope:registry=...), and query the registry directly for metadata with npm view <pkg>@<version> --json.

Confirm the package version and source

Before you retry, confirm the exact name, version or tag, namespace, and index or registry this environment is supposed to use. Most fixes here are about pointing at the right thing.

Check which registry npm is using:npm config get registry

If the package is scoped, verify scope registry mapping in .npmrc (example: @your-scope:registry=...).

List available versions:npm view <pkg> versions --json

If you requested a dist-tag, list tags:npm view <pkg> dist-tags --json

Retry with npm --verbose if the error message is truncated.

Why It Was Not Found

Usually this comes down to the configured registry does not contain the package/version you requested, auth is missing for a private registry or scoped package, or the requested version/tag/range is invalid or does not exist.

Prove the Source Resolves Correctly Now

Re-run npm view <pkg> for the same registry and confirm metadata is accessible, and re-run the original install and confirm the resolution error no longer appears.

How npm looks up package versions

npm resolves packages by fetching metadata from the registry, then selecting versions that satisfy semver ranges. Private registries and scopes add auth and routing requirements via .npmrc. If metadata lookup fails or no version satisfies constraints, npm throws a resolution error.

Avoid Version and Source Drift

To prevent this, keep registry config and auth in .npmrc under version control (where appropriate), pin versions (or use lockfiles) to avoid unexpected tag/range changes, and prefer a proxy/cache registry for CI stability.

Docs and source code

github.com/npm/cli/blob/417daa72b09c5129e7390cd12743ef31bf3ddb83/lib/commands/outdated.js

Open-source npm CLI code reference tied to this error code. - GitHub

    } catch (err) {
      // silently catch and ignore ETARGET, E403 &
      // E404 errors, deps are just skipped
      if (!['ETARGET', 'E404', 'E404'].includes(err.code)) {
        throw err
      }
    }