npm error code ETARGET (tested)

npm error code ETARGET is npm's "No matching version found" error: you (or a dependency) asked npm install for a version of a package that doesn't exist in the registry. We reproduced it against the real public registry four different ways — a nonexistent exact version, an unsatisfiable range, a stale pin in package.json, and a plain bad version string — to show the fix for each.

1. Exact version that doesn't exist

We ran npm install lodash@999.0.0 (lodash's real latest is 4.18.1):

$ npm install lodash@999.0.0
npm error code ETARGET
npm error notarget No matching version found for lodash@999.0.0.
npm error notarget In most cases you or one of your dependencies are requesting a package version that doesn't exist.
npm error A complete log of this run can be found in: /home/jacque/.npm/_logs/2026-10-03T09_25_59_324Z-debug-0.log

Fix: list what's actually published and install one of those:

$ npm view lodash versions --json
[
  ...
  "4.17.21",
  "4.17.23",
  "4.18.0",
  "4.18.1"
]
$ npm install lodash@4.18.1

2. Caret/tilde range that no published version satisfies

Ranges fail the same way as exact versions when nothing published matches. We ran npm install lodash@^999.0.0:

$ npm install lodash@^999.0.0
npm error code ETARGET
npm error notarget No matching version found for lodash@^999.0.0.
npm error notarget In most cases you or one of your dependencies are requesting a package version that doesn't exist.
npm error A complete log of this run can be found in: /home/jacque/.npm/_logs/2026-10-03T09_26_00_180Z-debug-0.log

Fix: this is usually a typo in a major version (we meant to type a version that exists). Check real versions with npm view <pkg> versions first, then use a range that actually brackets a published release, e.g. npm install lodash@^4.17.0.

3. A stale pin in package.json

The same error shows up with no arguments at all, when npm install reads a package.json that pins a version that was never published (or has since been unpublished/deprecated past availability). We committed this dependencies block:

{
  "name": "t3",
  "version": "1.0.0",
  "dependencies": {
    "lodash": "4.99.9"
  }
}

Then ran plain npm install:

$ npm install
npm error code ETARGET
npm error notarget No matching version found for lodash@4.99.9.
npm error notarget In most cases you or one of your dependencies are requesting a package version that doesn't exist.
npm error A complete log of this run can be found in: /home/jacque/.npm/_logs/2026-10-03T09_26_06_443Z-debug-0.log

Fix: edit the version string in package.json to a real one (check with npm view <pkg> versions), then run npm install again. If this came from a teammate's commit or a lockfile merge conflict, that's almost always the cause — a bad manual edit or a half-resolved merge.

4. Bad version string: still ETARGET, not a separate error code

We expected a plain invalid-semver string like not-a-semver-string to trip a different error (something like an invalid-tag error). We tested it directly with npm install lodash@not-a-semver-string:

$ npm install lodash@not-a-semver-string
npm error code ETARGET
npm error notarget No matching version found for lodash@not-a-semver-string.
npm error notarget In most cases you or one of your dependencies are requesting a package version that doesn't exist.
npm error A complete log of this run can be found in: /home/jacque/.npm/_logs/2026-10-03T09_26_01_083Z-debug-0.log

On npm 11.19.0, this is still ETARGET, not a distinct error code. npm treats any non-semver specifier as a candidate dist-tag (like latest or next); when no tag by that name exists either, it falls through to the same "no matching version" error. Don't assume the error code tells you whether the problem is a bad number or a bad string — read the notarget message line for the actual specifier npm tried.

5. General fix checklist

Symptom	Likely cause	Fix
Exact version, e.g. `pkg@999.0.0`	Typo or made-up version number	`npm view pkg versions`, install a real one
Range, e.g. `pkg@^999.0.0`	Typo in the major version of the range	Fix the range to bracket a published version
No args, fails on `package.json`	Stale/bad pin, often from a merge or manual edit	Edit the version in `package.json`, reinstall
Non-numeric string, e.g. `pkg@foo`	Meant a version or dist-tag that doesn't exist	Check `npm view pkg dist-tags` and `versions`

Frequently asked questions

What does npm error code ETARGET actually mean?

It means npm could not find any published version of the package that matches what you asked for — an exact version, a semver range, or a dist-tag. The registry has the package, just not that version.

Is ETARGET the same as an invalid version string error?

On npm 11.19.0 we tested a non-semver string (<code>lodash@not-a-semver-string</code>) and got ETARGET, not a separate error code. npm treats unrecognized strings as a dist-tag lookup first, and reports ETARGET when that also fails.

How do I see what versions actually exist?

Run <code>npm view <package> versions</code> for the full published list, or <code>npm view <package> version</code> for just the current <code>latest</code> tag.

Why did this suddenly start happening in CI but not locally?

Someone's local <code>node_modules</code> cache or lockfile may have an old resolved version that's since been unpublished or deprecated, while CI does a clean install straight from the registry and hits the real current state.

Can a private/scoped registry cause this even when the version exists on npmjs.com?

Yes. If your <code>.npmrc</code> points a scope at a private registry (e.g. Verdaccio or GitHub Packages) that doesn't mirror that version, you'll get ETARGET even though the public npm registry has it. Check which registry resolved the request in the error's <code>npm error notarget</code> line and your <code>.npmrc</code>.

Written with AI assistance. Measured on 2026-10-03 with npm 11.19.0 and Node.js v24.21.0 on Linux, running real `npm install` commands against the public npm registry for the `lodash` package (latest published version 4.18.1 at test time). Every error block below is verbatim terminal output we captured, not copied from docs. curl and the headers tool are free; Node.js and npm are free and open source.