Consumer problem
Components 3 is backed by PrimeReact 11. PrimeUI licensing explicitly continues to apply when applications consume PrimeUI through an internal wrapper or design system, and the public OEM guidance leaves framework/toolkit distribution requiring written clarification. PrimeReact types and pass-through slots also leak renderer details into the public Components contract.
A stabilization release deliberately kept that architecture unchanged so accessibility and correctness fixes could ship without forcing a renderer migration. The next major release should make the default Components package renderer-independent and openly licensed.
Decision
Build the public @cratis/components API on Cratis-owned markup, styling contracts, and types, using React Aria Components for accessible interaction behavior and TanStack Table only where advanced table state requires it.
Keep the foundation internal: consumers continue importing @cratis/components/*, not React Aria. A PrimeReact compatibility package may be provided as @cratis/components.primereact only after PrimeTek confirms the applicable redistribution/OEM terms in writing.
Arc command/query/dialog bindings remain owned by @cratis/arc.react; Components should not hide them behind optional rendering peers.
Consumer requirements
- Preserve custom design systems through Cratis-owned CSS variables, classes, stable part names, state data attributes, and per-part overrides.
- Preserve current command, query, dialog, selection, validation, pending/empty, localization, and accessibility behavior through shared contract specs.
- Publish no PrimeReact runtime imports or PrimeReact references in declarations from the default package.
- Keep JavaScript
Date compatibility at the public boundary while using internationalized date values internally where needed.
- Keep server filtering, sorting, and paging authoritative for query-backed tables.
- Provide a complete migration guide for provider setup, styling, pass-through replacement, direct Prime imports, dates, tables, dialogs, and notifications.
Validation gates
- Packed npm artifact works with npm, pnpm, and Yarn PnP.
- Arc 20, 21, and 22 consumer fixtures compile and load.
- Representative downstream applications compile against the packed artifact.
- Keyboard, focus, axe/browser, Storybook, SSR, light/dark, forced-colors, and responsive scenarios pass.
- Bundle and rendering performance are measured against the stabilization release.
- Existing public behavior specs pass against the new implementation.
- PrimeReact compatibility packaging does not ship until licensing/OEM scope is confirmed.
Deferred issues
This architecture is the intended resolution path for #162 and #163. Complete-result filtering from #159 must be designed as server-side filtering before paging rather than client filtering over one loaded page.
Consumer problem
Components 3 is backed by PrimeReact 11. PrimeUI licensing explicitly continues to apply when applications consume PrimeUI through an internal wrapper or design system, and the public OEM guidance leaves framework/toolkit distribution requiring written clarification. PrimeReact types and pass-through slots also leak renderer details into the public Components contract.
A stabilization release deliberately kept that architecture unchanged so accessibility and correctness fixes could ship without forcing a renderer migration. The next major release should make the default Components package renderer-independent and openly licensed.
Decision
Build the public
@cratis/componentsAPI on Cratis-owned markup, styling contracts, and types, using React Aria Components for accessible interaction behavior and TanStack Table only where advanced table state requires it.Keep the foundation internal: consumers continue importing
@cratis/components/*, not React Aria. A PrimeReact compatibility package may be provided as@cratis/components.primereactonly after PrimeTek confirms the applicable redistribution/OEM terms in writing.Arc command/query/dialog bindings remain owned by
@cratis/arc.react; Components should not hide them behind optional rendering peers.Consumer requirements
Datecompatibility at the public boundary while using internationalized date values internally where needed.Validation gates
Deferred issues
This architecture is the intended resolution path for #162 and #163. Complete-result filtering from #159 must be designed as server-side filtering before paging rather than client filtering over one loaded page.