Skip to content
Nilay Kabariya

Entry No.061·Fixes·Updated ·5 min read

npm error code ETARGET: No matching version found (5 causes)

npm error code ETARGET: no matching version found, sometimes with a date before. Five causes reproduced on npm 11 and 12, with the fix for each.

by Nilay#npm#nodeFIXED

The error, verbatim

Jump to the fix ↓
npm error code ETARGET
npm error notarget No matching version found for react@19.9.9.
npm error notarget In most cases you or one of your dependencies are requesting a package version that doesn't exist.
✓ Reproduced on Windows 11 Pro; Ubuntu on GitHub Actions (causes 1, 2, 5 re-run November 2)

Tested on

npm
11.9.0 / 12.2.0; 12.2.1 for cause 5 (October 31)
Node
24.14.0
Registry
registry.npmjs.org + a local Verdaccio 6
OS
Windows 11 Pro; Ubuntu on GitHub Actions (causes 1, 2, 5 re-run November 2)

✓ Last re-run on GitHub Actions · see the run · all repros

Contents
  1. 1. The version or tag doesn’t exist01
  2. 2. “with a date before”: a release-age setting02
  3. 3. A version that was just published: cached metadata03
  4. 4. A monorepo workspace asks for a version it doesn’t have04
  5. 5. A companion package isn’t published at that version05
  6. What didn’t work06
  7. How this was tested07

ETARGET means npm found the package, but not a version that matches what was asked for. The message always names both, so the first job is reading that line: No matching version found for react@19.9.9. Then check how the line ends. If it says with a date before …, the cause is different from all the others, and so is the fix.

I reproduced every cause below on Windows 11 with npm 11.9.0 and 12.2.0, against the real npm registry and a local registry where I could publish versions on demand.

The message Cause
…for react@19.9.9. The version or tag doesn’t exist
…for typescript@7.1.0-dev.20261011.1 with a date before 5/10/2026, 9:13:47 am. A release-age setting hides new versions
…for nk-demo@1.1.0., and you just published or upgraded it npm read old cached metadata
…for nk-demo@^2.0.0., and that package is in your monorepo A workspace range your local copy doesn’t satisfy

npm 12 prints the explanation on one line. npm 11 wraps it over two, which is the only difference I saw between them.

1. The version or tag doesn’t exist

The common one: a typo, a version that was never published, or one that was deprecated and removed. A dist-tag that doesn’t exist gives the same error, for example npm install react@beta-nope:

npm error code ETARGET
npm error notarget No matching version found for react@beta-nope.

Ask the registry what it actually has, then use one of those:

npm view react versions
npm view react dist-tags

If the version is in a dependency’s package.json rather than yours, the error names that package. Update the dependency that asks for it, or pin a version that exists with overrides.

2. “with a date before”: a release-age setting

This is the new one. To protect against compromised releases, which are usually caught within days, npm can refuse versions that are too new. npm 12 added min-release-age, in days. npm 11 and 12 both have the older before (an exact date). With any of them set, a version newer than the cutoff is treated as if it doesn’t exist:

npm error code ETARGET
npm error notarget No matching version found for typescript@7.1.0-dev.20261011.1 with a date before 5/10/2026, 9:13:47 am.

That TypeScript nightly was 19 hours old, and the date in the message is exactly 7 days before I ran the command, because my .npmrc had min-release-age=7. It’s printed in your computer’s own date format, so it can look like a random date rather than your setting.

Check whether a release-age setting is active, in the project and in your user config:

npm config get min-release-age
npm config get before

If you need one package to be newer than the cutoff, exclude just that package and keep the protection for everything else:

min-release-age=7
min-release-age-exclude=typescript

Otherwise, wait until the version is older than the cutoff, or lower min-release-age.

3. A version that was just published: cached metadata

npm caches each package’s version list. With --prefer-offline (or --offline, or a CI setup that adds it), npm trusts that cached list and won’t see a version published after it was saved. I published nk-demo 1.1.0 to my local registry after installing 1.0.0, then:

npm install nk-demo@1.1.0 --prefer-offline
npm error code ETARGET
npm error notarget No matching version found for nk-demo@1.1.0.

Run the install without --prefer-offline, so npm fetches the current version list:

npm install nk-demo@1.1.0

If the flag comes from a script or CI step you can’t change, clear the cache first:

npm cache clean --force

4. A monorepo workspace asks for a version it doesn’t have

In a monorepo, a workspace that depends on another workspace by name only gets the local copy if the local version matches the range. If it doesn’t, npm goes to the registry instead. When the package also exists there, but not in that range, you get ETARGET. In my test, app2 asked for nk-demo@^2.0.0 while the nk-demo workspace was at 1.1.0:

npm error code ETARGET
npm error notarget No matching version found for nk-demo@^2.0.0.

Make the range and the local version agree. Either bump the workspace’s own version, or change the range in the package that depends on it:

{ "dependencies": { "nk-demo": "^1.1.0" } }

If the name doesn’t exist on the registry at all, the same mismatch gives E404 instead of ETARGET.

5. A companion package isn’t published at that version

Some tools ship as two packages that are meant to share a version number, like prisma and @prisma/client. While Prisma 8 is in release candidates, the latest tag of prisma points to 8.0.0-rc.29, but @prisma/client’s latest is still 7.10.1, and there is no @prisma/client@8.0.0-rc.29. Pinning both to the same version failed on npm 12.2.1 on October 31:

npm error code ETARGET
npm error notarget No matching version found for @prisma/client@8.0.0-rc.29.
npm error notarget In most cases you or one of your dependencies are requesting a package version that doesn't exist.

Check each package on its own before pinning them together:

npm view prisma dist-tags
npm view @prisma/client dist-tags

The prisma CLI itself installed fine at 8.0.0-rc.29. The mismatch is only in the second package, so the error names it, not the one you were thinking about. If you’re trying the Prisma 8 release candidates, Prisma 8’s other changes start with prisma generate.

What didn’t work

How this was tested

npm 11.9.0 (bundled with Node 24.14.0) and npm 12.2.0, on Windows 11 Pro. The missing-version, missing-tag and release-age cases ran against registry.npmjs.org on October 12, 2026, each with an empty cache, using the TypeScript nightly published the day before and the current Claude Code release. The cached-metadata and workspace cases used a local Verdaccio 6 registry on 127.0.0.1, so I could publish new versions of a test package (nk-demo) between installs. No packages were published to the public registry. Every message above is the real output.

November 2, 2026: causes 1, 2 and 5 were re-run on npm 12.2.1 (Node 24.22.1, GitHub Actions ubuntu-latest). react@beta-nope still failed with ETARGET. With min-release-age=7, that day’s TypeScript nightly (7.1.0-dev.20261102.1) failed with No matching version found ... with a date before, typescript@next quietly installed 7.0.2 instead, and min-release-age-exclude=typescript let the nightly install. @prisma/client@8.0.0-rc.29 still didn’t exist next to prisma@8.0.0-rc.29. Causes 3 and 4 need a private registry and weren’t re-run. The script and output are public.

— N.K., end of entry No.061

Useful? Pass it on:Post on XFollow @EmotionalMatter

Related entries

  1. No.037

    npm 12 breaking changes, tested: what actually breaks

    The headline change, install scripts blocked by default, broke puppeteer, cypress, sqlite3 and Claude Code's npm package, and silently skipped lefthook's git hooks. esbuild, bcrypt, sharp and better-sqlite3 kept working. Every install reported success, and the only sign was a warning after the summary.

    TESTED6 minWindows
  2. No.093

    Fix: bigint Failed to load bindings, pure JS will be used

    bigint: Failed to load bindings, pure JS will be used. Why npm 12 shows it on every install, whether it matters, and how to get the native build back.

    > bigint: Failed to load bindings, pure JS will be used (try npm run rebuild?)

    FIXED3 minWindows
  3. No.091

    Fix: npm error code EALLOWREMOTE (and EALLOWGIT), tested

    npm error code EALLOWREMOTE: Fetching packages of type remote have been disabled. Every case reproduced on npm 12, from npx to npm ci, with each fix.

    > npm error code EALLOWREMOTE

    FIXED4 min
  4. No.086

    npm error code EACCES: permission denied, 3 causes tested

    npm error code EACCES with syscall mkdir or open: a global install, a cache that sudo left behind, or Docker. Each reproduced, with the fix that lasts.

    > npm error code EACCES

    FIXED2 min

Post card · Every Sunday

What broke this week.

One email on Sundays: the Node, TypeScript, Python and AI SDK releases that broke builds that week, each one reproduced, with a link to the fix that worked. Never shared, and you can leave any time.

— Nilay

or follow by RSSor on X

By subscribing you agree to the privacy note. One click to leave.

tip: paste the exact error text