CratisComponentsConfig is Partial<PrimeReactProps>, so every consumer's root wiring is typed by a commercial third-party package

[woksin]

What happens

CratisComponentsProvider's configuration type is an alias for PrimeReact's provider props, so every consuming application's root wiring is typed by a third-party commercial package.

In @cratis/components@3.4.0:

// dist/esm/Common/CratisComponentsProvider.d.ts
type CratisComponentsConfig = Partial<PrimeReactProps>;

PrimeReactProps comes from @primereact/types, which carries the PrimeUI commercial licence (see #161). The consequence is that the single most universal touch-point in the library — the provider every app mounts once at its root — cannot be typed, wrapped or configured without resolving a commercial type.

Evidence

Measured against the published @cratis/components@3.4.0 artifact with primereact@11.1.0 / @primereact/types@11.1.0.

Of the 27 distinct PrimeReact symbols in Components' public API, 18 are reachable only through the pt / ptOptions pass-through — an escape hatch a consumer can decline to use. CratisComponentsConfig is not in that category: it is the type of the provider's only prop, so it is unavoidable for every consumer, including one that never writes a single pt.

In a representative consumer, the root provider passes license, ripple, locale, locales, plus a spread of styledMode({ preset }) contributing theme and defaults. Every one of those keys is a PrimeReact provider key. There is no Cratis-owned vocabulary for "configure Cratis Components"; there is only PrimeReact's, re-exported under a Cratis name.

What it costs a consumer

• The type is load-bearing and unavoidable. Any wrapper component a consumer writes around CratisComponentsProvider — which is the normal pattern, since apps want one place for locale + theme + license — must import and satisfy a commercial type.
• It makes the root provider a structural blocker. Consumers cannot configure Cratis's binding behavior without resolving PrimeReact's provider type; other PrimeReact touch-points can remain adapter-local thin widget wrappers or theming.
• It silently widens the licence surface. Upgrading to Components 3.x transfers PrimeReact 11's commercial PrimeUI licence obligation to the consumer, undocumented and unconfigurable #161 documents that the obligation arrives through the peer range and is invisible in Components' own MIT metadata. This alias is the mechanism by which it reaches a consumer's type surface too, not just its runtime.
• It blocks the direction Prove a renderer-neutral Arc React query/table state seam #109 already sets — a headless binding layer cannot be provider-configured through a type that is PrimeReact's.

Honest limit: this costs no runtime behavior today and has caused no defect. It is a coupling and licence-surface concern, not a bug.

Suggested fix — the seam

Define a Cratis-owned configuration type naming only what Cratis's own components consume, and let the adapter extend it:

interface CratisComponentsConfig {
    locale?: string;
    locales?: Record<string, LocaleMessages>;
    toaster?: boolean;
    // …the keys Cratis components actually read
}

with kit-specific configuration (theme, defaults, unstyled, pt, ptOptions, license, ripple) accepted through a documented, explicitly adapter-scoped extension point rather than by aliasing the whole third-party type.

license is worth calling out: #161 asks for a first-class licence-configuration point, and this is where it would naturally live — as an adapter-owned key with a documented name, rather than as an inherited PrimeReact prop.

What is explicitly not being asked for

• Not removing the ability to configure PrimeReact. A consumer using the PrimeReact implementation should still be able to reach every provider key it has today.
• Not a breaking rename of CratisComponentsProvider or its value prop shape.
• Not any change to PrimeTek's licensing or to how the licence key is verified.

[woksin]

Deferred from closed PR #168 so the provider contract can be redesigned as part of the focused React Aria major release rather than changed inside a mixed stabilization release. The future public configuration and styling contracts will be Cratis-owned and preserve custom token/slot styling without exposing renderer types.

[woksin]

Addressed by the unmerged Components 4 major PR #177: the default package/provider/public types no longer require or expose PrimeReact/PrimeUI. Keep this issue open until #177 is reviewed and merged; do not mark released from local evidence.

[cratis-stagehand]

Thanks for opening this - it has been received and will be looked at.

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.