`mint` releases are published before their pinned `@mintlify/*` dependencies, so `npm install -g mint` fails with ETARGET for up to ~5 minutes after every release

[NathanEckert]

Summary

Since 2026-09-03, mint and @mintlify/cli are being published to npm before the @mintlify/* packages they pin to exact versions. During that gap npm install -g mint is unresolvable and fails with ETARGET, because the newly-published mint resolves to a dependency version that does not exist on the registry yet.

The window has lasted 0.8–5.1 minutes and has affected 21 of the 28 releases published since 2026-09-03. It self-heals once the remaining packages finish publishing, so it shows up as unexplained, intermittent CI failures rather than a reproducible bug.

Symptom

$ npm install -g mint
npm error code ETARGET
npm error notarget No matching version found for @mintlify/link-rot@3.0.1348.
npm error notarget In most cases you or one of your dependencies are requesting
npm error notarget a package version that doesn't exist.

The package named in the error varies by release (link-rot, previewing, validation, models, common) — npm reports whichever missing version it reaches first, so the error text is not a stable signal for the underlying problem.

Root cause: publish ordering

mint pins @mintlify/cli to an exact version, which in turn pins six @mintlify/* packages to exact versions. The release pipeline appears to publish these concurrently rather than in topological order, so parents can become visible on the registry before their children.

Registry publish timestamps for the current latest, mint@4.2.893:

package	published (UTC)	vs mint
@mintlify/scraping@4.0.1014	22:33:19	−0.2 min
@mintlify/prebuild@1.0.1300	22:33:23	−0.2 min
mint@4.2.893	22:33:34	—
@mintlify/cli@4.0.1496	22:34:26	+0.9 min
@mintlify/common@1.0.1146	22:34:33	+1.0 min
@mintlify/previewing@4.0.1372	22:35:02	+1.5 min
@mintlify/link-rot@3.0.1348	22:35:37	+2.1 min
@mintlify/validation@0.1.854	22:38:23	+4.8 min

Some children land before mint and some after, which is what a concurrent publish looks like. mint@4.2.893 was therefore unresolvable from 22:33:34 until 22:38:23 — 4 minutes 49 seconds.

When it started

This is a regression, not long-standing behaviour. The dependency structure has not changed (mint → @mintlify/cli exact → 6 pinned leaves, unchanged since at least 4.2.600 in June). Only the publish order changed.

• 2026-06-03 → 2026-09-03 — 259 releases, leaves consistently published 0.1–0.4 min before mint. Zero affected releases.
• 2026-09-03 onward — 21 of 28 releases affected. First affected release: 4.2.867 (2026-09-03T17:47:48Z, +4.0 min). Last clean release of the old regime: 4.2.866 (2026-09-03T07:33:49Z).

Recent affected releases and their windows:

4.2.885  2026-09-10T22:03:38  +2.0 min
4.2.886  2026-09-11T02:21:20  +3.0 min
4.2.887  2026-09-11T05:54:35  +4.0 min
4.2.888  2026-09-11T19:18:23  +4.0 min
4.2.890  2026-09-12T02:15:23  +0.9 min
4.2.891  2026-09-12T21:38:17  +1.2 min
4.2.892  2026-09-14T17:56:45  +5.1 min
4.2.893  2026-09-14T22:33:34  +4.8 min

The largest window size observed so far is 5.1 min.

How to verify

This is visible in registry metadata. For any mint version, compare its own publish time against the publish times of the exact versions in its @mintlify/* closure:

$ npm view mint@4.2.893 dependencies
{ '@mintlify/cli': '4.0.1496' }

$ npm view mint time --json | jq -r '."4.2.893"'
2026-09-14T22:33:34.059Z          # mint published

$ npm view @mintlify/cli@4.0.1496 dependencies    # six exact pins, incl. validation 0.1.854
$ npm view @mintlify/validation time --json | jq -r '."0.1.854"'
2026-09-14T22:38:23.231Z          # 4m49s later -> ETARGET for that whole interval

Impact

It has already hit at least one other public project (orbi-build/orbi#744, 2026-09-12, on @mintlify/link-rot@3.0.1345), where it was initially misdiagnosed as Mintlify having shipped a permanently broken release.