peerDependencies pin @mittwald/react-use-promise to ^2.6.0, which cannot be satisfied with its 4.x release

[mfal]

The published packages declare a @mittwald/react-use-promise peer range that
cannot be satisfied alongside its current release, so any project combining them
with @mittwald/flow-react-components gets a peer-range warning on install.

At 4.449.0, three published packages declare:

"peerDependencies": { "@mittwald/react-use-promise": "^2.6.0" }

• @mittwald/api-models
• @mittwald/api-client-commons
• @mittwald/api-client

@mittwald/react-use-promise is at 4.2.2. The highest version ^2.6.0
admits is 2.9.9, and @mittwald/flow-react-components requires ^4.2.2 in
both dependencies and peerDependencies — so the two ranges are disjoint:

^2.6.0 ∩ ^4.2.2  →  no intersection
semver.satisfies("4.2.2", "^2.6.0")  →  false

Yarn reports the non-overlapping ranges during install of a project that uses
both.

Why this has gone unnoticed

@mittwald/react-use-promise is optional: true in peerDependenciesMeta, so
this is a warning rather than an install failure. Nothing breaks — it is noise
that every consumer of both libraries sees and has to decide to ignore.

Is the range deliberate?

Possibly not: 3.0.0 and 4.0.0 of react-use-promise were React-19 majors
("React 19", then "switched to React 19 (only)"), not API rewrites of the hooks
these packages use. That reads like a range that was never widened rather than a
constraint someone chose. The devDependencies entry sits at ^2.6.2, which
fits that reading.

If there is a reason to hold it — something in useSuspense/usePromise that
changed, or a deliberate React 18 floor — that is worth writing down, because
from the outside it looks like an oversight.

Suggested fix

Widen the peer range to cover the current majors, e.g.

"peerDependencies": { "@mittwald/react-use-promise": "^2.6.0 || ^3.0.0 || ^4.0.0" }

in all three packages, and bump the devDependencies entry so CI actually
exercises the version consumers install.

---

Found while upgrading a project that uses both @mittwald/flow-react-components
and @mittwald/api-client. Verified against the npm registry and master at the
time of writing; happy to open a PR if the widened range is what you want.

[mfal]

Thanks for the detailed write-up — the disjoint-range diagnosis is correct. I measured the actual compatibility before widening, and there is a wrinkle that changes the suggested fix.

Method

For each candidate version: pin it as the devDependency in packages/commons, packages/models and packages/mittwald, yarn install, then nx run-many -t build (which is tsc per package) and the Jest suites.

Version	build (tsc)	tests
2.6.2 (status quo)	✅	✅
3.0.4	✅	–
4.0.2	✅	✅ 17 commons + 5 models
4.1.0	❌ TS2305	–
4.2.2 (latest)	❌ TS2305	–

The API is compatible — the packaging is not

Every symbol used here is unchanged or only widened between 2.6 and 4.2.2:

• getAsyncResource(fn, params, { tags, loaderId }) — identical signature (the parameter type was renamed AsyncFn → LoaderFn in 4.0, but structurally widened: it now also accepts sync loaders)
• refresh({ tag }) — Tag was widened from string to string | [string, string]; a plain string still fits
• Store<T> from /store with get / set / getAll; StorageEntryOptions.tags still accepts string[]
• usePromise(..., { useSuspense: false }) → .hasValue — unchanged
• AsyncResource<T>, asyncResourceStore — present throughout

So there is no hidden constraint in useSuspense / usePromise holding the range back. Your reading is right: it was never widened.

What does break is a packaging regression introduced in 4.1.0. From that version on, the shipped .d.ts files use extensionless relative imports:

4.0.2:  export * from "./resource/refresh.js";
4.1.0+: export * from "./resource/refresh";

The package is "type": "module", and this repo compiles with moduleResolution: NodeNext, so TypeScript cannot resolve those paths and the whole export surface collapses:

src/react/ApiCallAsyncResourceFactory.ts(1,10): error TS2305: Module
'"@mittwald/react-use-promise"' has no exported member 'getAsyncResource'.
src/react/types.ts(6,10): error TS2305: Module
'"@mittwald/react-use-promise"' has no exported member 'AsyncResource'.

dist/esm/index.js still carries the .js extensions, so this is types-only. Consumers on moduleResolution: bundler — likely including @mittwald/flow-react-components — never see it; consumers on NodeNext/Node16 do.

The React 19 concern is already resolved upstream

Worth recording, since it was the stated reason to suspect the majors:

Version	peerDependencies.react
2.6.2	>=17.0
3.0.0	>=19.0
3.0.4	>=18.3
4.0.0	>=19.0
4.0.2 – 4.2.2	>=18.3

Both React-19 majors were walked back in a patch. Widening the range forces React 19 on nobody.

One side effect worth flagging

client-react.ts does export * from "@mittwald/react-use-promise", so the type exports removed in 3.x/4.x — AsyncFn, AsyncLoader, TagPattern, and the deprecated AsyncResource.watch() — also disappear from what @mittwald/api-client re-exports. Nothing in this repo uses them, but it is a downstream type-level break that arrives independently of the peer range.

What I'm doing

Widening the peer range as you suggested, to ^2.6.0 || ^3.0.0 || ^4.0.0 in all three packages. That is the right declaration: the peer is resolved in the consumer's tree, and for bundler-resolution consumers 4.2.2 genuinely works.

The devDependency, however, cannot go to ^4.0.2 — caret would resolve 4.2.2 and red the build. It goes to ~4.0.2, the highest range that actually compiles here. So CI will exercise 4.0.x rather than the 4.2.x consumers install; that gap closes once the .d.ts extensions are restored upstream in @mittwald/react-use-promise, after which the devDep can move to ^4.2.3 with no change to the peer range.

PR incoming.