Release v2.0.0

Summary

PrimeReact 11 ships 80 modules where 10.9.8 shipped 117, replaces monolithic components with compositional part namespaces, and ships no CSS at all. All four Scene JavaScript packages move together.

Important

PrimeReact 11 is not MIT. primereact, primeicons 8, @primereact/core, @primereact/headless, @primeuix/themes and @primeuix/styled are all under the commercial PrimeUI license, and a license key is required regardless of how you style — the check runs in PrimeReactProvider on mount with no condition on unstyled, on theme, or on NODE_ENV. Without a key, every page logs a warning and shows an "Invalid PrimeUI License" banner in development and production alike. See the migration page.

Changed

• @cratis/scene.primereact, @cratis/scene.components, @cratis/scene.blueprint.default and @cratis/scene.blueprint.components now require primereact ^11.0.0, primeicons ^8.0.0 and @cratis/components ^3.0.0, and declare @primereact/core and @primereact/headless where they import them directly.
• 13 abstract names follow a PrimeReact rename without changing their Scene name — dropdown is now Select, calendar is DatePicker, overlayPanel is Popover, tabView is Tabs, and so on.
• multiSelect is re-expressed over Select's multiple; orderList and pickList over @primereact/headless hooks, which ship the behavior but no presentation.
• Theming is rebuilt on @primeuix/themes presets. A theme is now an object handed to PrimeReactProvider rather than a stylesheet to load, so switching neither fetches nor flashes, and a theme name can no longer 404. usePrimeReactTheme returns the provider configuration instead of mutating the DOM.
• The theme catalog is 24 themes across the Aura, Lara, Nora and Material families, replacing the 25 PrimeTek v10 themes. Their license is recorded as PrimeUI Commercial.
• PrimeReactProvider is now mandatory anywhere Scene components render — PrimeReact 11 throws without it rather than falling back to a default configuration.

Added

• 14 abstract names whose PrimeReact component was removed in v11 are now backed by Cratis-owned implementations: menubar, megaMenu, tieredMenu, panelMenu, tabMenu, steps, dock, splitButton, confirmDialog, column, treeSelect, blockUI, scrollTop and image.
• MenuItem and TreeNode are exported from @cratis/scene.primereact. PrimeReact 11 removed primereact/menuitem and primereact/treenode, and the authored { label, icon, items } shape was always Scene's vocabulary.

Removed

• cascadeSelect, inputMask, treeTable and virtualScroller are no longer declared. PrimeReact 11 removed all four with no equivalent and no headless hook. Use dropdown with grouped options or treeSelect instead of cascadeSelect, inputText with validation instead of inputMask, tree or dataTable instead of treeTable, and dataTable's own scrolling instead of virtualScroller.
• applyPrimeReactTheme and primeReactThemeStylesheet are gone. They swapped and resolved a compiled theme stylesheet, and PrimeReact 11 has none — primeReactThemePreset resolves a theme name to a preset object instead.
• 13 v10 themes have no v11 counterpart and are not carried over: saga-blue, vela-blue, arya-blue, bootstrap4-light-blue, bootstrap4-dark-blue, soho-light, soho-dark, viva-light, viva-dark, nano, mira, fluent-light and tailwind-light.

Deprecated

• Reduced capabilities forced by PrimeReact 11: password loses feedback and toggleMask, colorPicker loses its overlay mode, rating loses cancel, listBox loses filter, multiSelect loses display and maxSelectedLabels, carousel loses numScroll, paginator loses rowsPerPageOptions, dataTable loses size='normal', and column no longer carries editor, frozen, footer, colSpan or expander.

---

Caution

Sidebar is not Sidebar. PrimeReact 10's Sidebar is v11's Drawer, and v11 gives the name Sidebar to an unrelated new app-shell primitive. A name-preserving port compiles cleanly and silently swaps an overlay for a static shell. Both affected sites — the sidebar adapter and the default blueprint's config panel — are on primereact/drawer.

🤖 Generated with Claude Code

Release v1.1.0

Added

• UiProfile gained Layout and Theme — the application shell a target renders inside, and the visual theme it applies. Screenplay's ui profile could already state both (layout AppShell, theme Aurora), but the model had nowhere to hold them, so translation dropped them.

Both belong on the profile rather than on a screen: a screen that named its own shell or theme would stop being portable across targets, which is the reason profile selection exists at all.

🤖 Generated with Claude Code

Release v1.0.0

Added

• Packages. A ui profile lists packages by name; ScenePackage is the declaration behind such a name — what it contributes (components, layouts, screen and dialog templates, themes) and what else has to be active for it to work. Kinds are ComponentLibrary, Styling and Blueprint.
• Dependency resolution. PackageDependencyResolver expands a chosen set of packages into the complete list, ordered so a package always follows what it depends on — which is also the correct override priority. Missing dependencies, version conflicts and cycles are reported rather than guessed at. PackageCatalog answers what a package picker asks: which component libraries are a base to build on, and what else fits what is already selected.
• Screen and dialog templates. ScreenTemplate is a reusable shape that goes inside a layout, at module, feature or slice level; FitsSlot names the slot on its parent it fills, and ScreenTemplateResolver turns those names into a tree. The same rule applies at every level, so nesting has no depth limit. DialogTemplate is the same for overlays, which fill no slot.
• Themes carry attribution. Theme gained design tokens plus Author, AuthorUrl and License, so a theme adopted from elsewhere credits its original creator.
• @cratis/scene.primereact — 87 component names across PrimeReact's families, and 25 of PrimeTek's free themes, each credited.
• @cratis/scene.components — the Arc-bound Cratis Components composites, with a binding registry so a screen can name a query or command that a host resolves to a real class at render time.
• @cratis/scene.tailwind — the styling package component libraries declare themselves written against.
• @cratis/scene.blueprint.default — application shells with eight menu modes, 23 screen templates, 3 dialog templates and two themes.
• @cratis/scene.blueprint.components — whole Arc-bound pages built from Cratis Components, layered on the default blueprint rather than shipping a rival shell.

Changed

• A layout and a template are now different things. A Layout is an application's base navigational look and an application has one; a ScreenTemplate goes inside it and an application has many. They were previously the same word for both.
• FlowContainer carries its Kind. C# distinguished a FlowRow from a FlowColumn by type, but the TypeScript mirror could not — interfaces with identical members are the same type — so a renderer had no way to tell a row from a column.

🤖 Generated with Claude Code

Release v0.7.0

Added

• Layout.Arrangement: an optional FlowArrangement/FreeformSlotArrangement describing how a layout's own named slots position relative to each other, filling a gap where Screenplay's template/row/column/grid/variant constructs (which arrange slots) had nowhere to go in the object model - only a single slot's own filled content could be arranged before this
• FlowSlotLeaf/SlotPlacement: the slot-referencing counterparts to FlowLeaf/ElementPlacement, used only within a Layout's own arrangement tree
• FreeformSlotArrangementEvaluator (+ TypeScript evaluateFreeformSlotArrangement): selects a Layout's macro placement variant for a size class, mirroring FreeformArrangementEvaluator

Context

Found while implementing Cratis/Stage#37 (the Screenplay → Scene translation seam) - Screenplay's layout construct places named slots via template/variant blocks, but Layout had no field to receive that structure, only Slot.Arrangement for a slot's own content. Fully additive: no existing type's shape changed, and FlowArrangementEvaluator is reused unmodified since it never inspects leaf content.

Release v0.6.0

Added

• UiStarter model type: a packaged, versioned UI starting point bundling a package list, compatible themes, and a gallery of sample screen names (#6)
• StarterProfileBuilder / buildStarterProfile: builds the sandboxed UiProfile a starter's gallery boots through, scoped to exactly its own package list (#6)
• StarterThemeValidation / incompatibleStarterThemes: finds which of a starter's declared themes are incompatible with its own packages, reusing the theme compatibility engine (#6)

Release v0.5.0

Added

• ThemeCompatibility.IncompatiblePackages()/incompatiblePackages() and IsCompatible()/isThemeCompatible() - reuse the exact rule Screenplay's compiler already applies (ValidateThemes): every package a ui profile declares must be in the theme's compatibleWith list, with no implicit exemption for core. Sharing this rule here means Stage's build-time warning and Studio's design-time theme-picker filtering don't each reimplement it. (#5)
• ThemeCompatibility.ApplicablePackages()/applicableThemePackages() - the renderer-facing half: the packages a profile activates that a theme also declares compatible, which Scene.React scopes token application to (rather than applying a theme's tokens globally). Computing it fresh from the current theme/profile pair, rather than caching a resolved result, is what makes theme switching a live re-resolution with no reload. (#5)
• A shared JSON fixture corpus (theme-compatibility-fixtures.json) asserted independently by both the C# and TypeScript specs, following the pattern established in #3/#4.

Notes

The theme token model's own shape (colors, spacing, typography) is explicitly out of scope for this issue, confirmed by its own text - this PR only builds the compatibility check and the package-scoping helper a future token-application layer in Scene.React will consume; it does not attempt to design or apply actual tokens.

Release v0.4.0

Added

• aggregateContributions() (@cratis/scene.engine) - collects every contribution targeting a given contribution point, ordered ascending by its explicit order (unordered contributions sort after every ordered one, in their original relative order). Resolving which contribution point a contribute to targets already happens before a Contribution exists in Scene.Model (see its own doc comment), so there was no ambiguity left for the engine to resolve here, only ordering - this is narrower than the issue's original proposal, which assumed the engine would still walk a nearest-enclosing resolution; that already happened upstream. (#2)
• NavBar widget (@cratis/scene.react) - renders the aggregated Navigation contributions. How navigate to <Screen> becomes a concrete route is a caller-supplied renderRoute callback rather than a fixed URL scheme, so the same widget works unmodified across renderers, per the issue's own "configurable per renderer" requirement. (#2)
• extractNavigationItem() - reads a NavigationItem out of a Navigation contribution's ExternalComponent.properties bag.

Notes

extractNavigationItem's property-bag key contract (label, targetScreen, routeParameterBindings, order, group - the same names as NavigationItem's own fields) is a Scene#2 design choice made without a real Screenplay-to-Scene translation to confirm it against - Stage#37 (the Screenplay → Scene seam) hasn't been built yet. Documented as an assumption in the function's own doc comment; Stage#37 should either match this contract or this function should move to match whatever it actually emits.

Release v0.3.0

Added

• SizeClassCalculator.Compute() (C#) / computeSizeClass() (TypeScript) - computes the current width x height size class from actual available dimensions, shared by every renderer so they all agree on when a class boundary is crossed. (#4)
• FlowArrangementEvaluator.Evaluate() / evaluateFlowArrangement() - selects the most specific matching when width/height <class> override's tree for the current size class (both dimensions targeted beats one; the last declared wins among equally specific matches), falling back to the base tree when nothing matches. (#4)
• FreeformArrangementEvaluator.Evaluate() / evaluateFreeformArrangement() - selects the placement variant with an exact size-class match, or nothing - deliberately no fallback, matching the language's own "warn, don't silently pick" design for a size class with no matching variant. (#4)
• FlowArrangement gained an Overrides list (C#) / overrides (TypeScript) - the model previously had no field at all for Screenplay's when width/height <class> override construct, unlike FreeformArrangement which was already keyed by size class.
• A shared JSON fixture corpus (layout-evaluation-fixtures.json) asserted independently by both the C# and TypeScript specs, following the same pattern established for the package resolver in #3/#9.

Notes

Per Scene#8's original design (confirmed against its merged PR description), Slot.Arrangement is per-slot, not per-layout - this evaluation engine works against that shape as-is and does not assume every slot in a layout shares one arrangement mode.

Release v0.2.0

Added

• PackageResolver.Resolve() (C#, Cratis.Scene.Engine) and resolveComponentName() (TypeScript, @cratis/scene.engine) - resolve a bare or package-qualified component name against a ui profile's package list. A bare name walks the package list from highest to lowest priority (core always the lowest-priority fallback); a package-qualified name (e.g. Internal.Widgets.TrendChart) resolves directly against its named package, bypassing priority order entirely. (#3)
• Every resolution also reports which other active packages declared the same bare name but were shadowed by the winner, directly answering the issue's own open question ("why did my button render as PrimeReact's and not core's") without needing separate CLI tooling. (#3)
• A shared JSON fixture corpus (package-resolution-fixtures.json) asserted independently by both the C# and TypeScript specs, so the two implementations of the algorithm cannot drift apart - the same pattern scene-model-shape.json already establishes for Scene.Model's shape.
• New Cratis.Scene.Engine C# project, sibling to Scene.Model, mirroring the existing TypeScript model/engine package split - keeps Scene.Model's strict shape-parity manifest free of behavioral types.

Notes

Wiring this resolver into SceneElementView/ComponentRegistry's actual rendering path (resolving an entire element tree's component names before it renders) is left to Stage#39 and StudioIssues#160, which this issue explicitly lists as downstream consumers - not attempted here.

Release v0.1.0

Added

• Cratis.Scene.Model (C#) — the platform-agnostic Screen object model: the SceneElement → VisualElement → FrameworkElement → Control → Panel/ItemsControl/ContentControl/ExternalComponent element hierarchy, Layout (flow and freeform arrangement per slot, width × height size classes), Form (the three population/mapping tiers), contribution points and navigation, and UiProfile/Theme. No React, DOM or CSS vocabulary anywhere in this project.
• @cratis/scene.model — the TypeScript mirror, hand-maintained and guarded by a real cross-language parity spec: a shared scene-model-shape.json manifest that both a C# spec (reflection over the assembly) and a TypeScript spec (walking each type's own PropertyNames const) assert against independently, so a desync on either side fails its own build.
• @cratis/scene.engine — the Renderer<TOutput> contract a renderer implements (one method per concrete element kind), and a renderElement() tree walk. Binding resolution is injected via a BindingResolver callback rather than solved here — the profile/contribution/layout/theme resolution engines are separate, later issues.
• @cratis/scene.react — implements the renderer contract against real React/DOM, with a small core component set (core:text/button/card) and Storybook wired at the package level.
• Repository scaffold: .ai/ instruction corpus and its Copilot/Claude/Codex adapters, build/lint/format config, and CI workflows (dotnet + JS build, NuGet + npm trusted publishing, semver label gate) — copied from Cratis/Arc, the closest real dual-stack framework repo.

Notes

• The design-time editor building on this object model belongs in Studio (StudioIssues#156), not here.
• Verified end to end: dotnet build/dotnet test clean (Debug + Release, 0 warnings), yarn ci clean across all three JS packages, yarn build-storybook succeeds, and the parity spec genuinely fails on both sides when deliberately desynced (verified, then reverted).

(#1)