Schemas Laravel Package

Product Decisions This Supports

• Build vs. buy for form/UI schema layers. Laravilt/Schemas gives us a declarative, server-driven schema for rendering forms, wizards, and layouts. The build-vs-buy question for internal admin tooling and CRUD-heavy back-offices should now lean toward "buy/adopt" rather than hand-rolling per-feature form components.
• Framework-agnostic frontend roadmap. v1.1.0 adds React support alongside the existing Vue path. This is a strategic unlock: it removes a hard coupling between our schema definitions and a single frontend stack, and it de-risks future frontend migrations (we can introduce React in one surface area without rewriting every schema).
• Laravel 13 forward-compatibility. Explicit Laravel 13 compatibility support is a lifecycle signal. It supports scheduling the package on the upgrade roadmap and reduces the risk of being blocked from a framework upgrade by a UI/schema dependency.
• Wizard and multi-step flow use cases. The localization composable fix in Wizard suggests a maturing multi-step-flow capability — relevant for onboarding flows, checkout-style sequences, approval workflows, and guided configuration screens that we would otherwise build bespoke.
• Layout and styling as product surface. Fixes to layout rendering, reactive updates, and Tailwind classes mean the visual/interaction layer is being actively hardened. This supports decisions to use the package for customer-visible surfaces, not just internal admin, though see the caution under "When to Consider."
• Release cadence as a health signal. Mixed dependabot bumps plus substantive feature/fix work from the maintainer indicate an actively maintained project with CI hygiene. Useful input for the "is this a safe dependency" call and for setting expectations on support responsiveness.

When to Consider This Package

Consider adoption when:

• We are building schema-driven or configuration-driven UI in a Laravel application — dynamic forms, admin panels, wizards, settings screens — where the field/step definitions can live in PHP rather than being duplicated in frontend components.
• Our frontend stack is Vue or React and we want one schema contract to serve either, especially if a framework migration is on the horizon.
• We need multi-step flows (wizards) with localization and consistent layout/styling, and the alternative is building that scaffolding in-house.
• We are planning a Laravel 13 upgrade and want dependencies that already declare support.
• We want Tailwind-native rendering rather than a package that ships its own opinionated CSS system.

Look elsewhere when:

• The surface requires highly bespoke interaction design that a schema abstraction would fight rather than enable — heavy drag-and-drop editors, canvas-style UIs, or complex real-time collaboration.
• We are on a non-Laravel backend or a frontend-only architecture; the value here is the Laravel-side schema authoring model.
• The organization has no appetite for a younger, single-maintainer ecosystem package on a critical path. The version history (v1.0.x → v1.1.0) and the "first contribution" note suggest a young project; mission-critical paths warrant a spike, a fallback, or a fork/contribution plan.
• Filament or another mature admin framework already covers the need with a larger community and longer support track record — adopting both would be redundant.
• We need stable, documented public APIs with long deprecation windows. This release includes behavioral fixes to rendering and reactivity, which is healthy but implies the interaction layer is still settling.

How to Pitch It (Stakeholders)

For executives (one paragraph): Laravilt/Schemas is a Laravel package that lets us define forms, multi-step wizards, and page layouts once in backend code and render them consistently in Vue or React. The new v1.1.0 release matters for three reasons: it adds React support, so we are no longer locked to one frontend framework; it declares Laravel 13 compatibility, protecting our upgrade path; and it lands fixes to layout rendering, reactive updates, and Tailwind styling, meaning the package is being actively hardened rather than abandoned. Net effect: lower effort to ship internal tools and configuration-heavy screens, less duplicated frontend code, and reduced platform risk. The tradeoff is dependency on a young, essentially single-maintainer project — so we recommend adopting it where it accelerates delivery, with a short evaluation spike before it touches revenue-critical surfaces.

For engineering: This is a schema-authoring layer, not a UI framework replacement. Expect to define schemas server-side and let the package handle rendering, wizard stepping, localization, and Tailwind class application. The v1.1.0 work that affects us day-to-day is the Wizard localization composable fix and the Schema rendering/reactivity/Tailwind fixes — validate these against any existing layout-heavy screens, since rendering-behavior fixes can shift visual output. The React and Laravel 13 additions are additive and low-risk to adopt. Dependabot churn in CI actions is noise. Recommended next step: timebox a spike on one real screen (ideally a wizard with localization and a non-trivial layout) and confirm upgrade behavior on Laravel 13 and on both Vue and React before committing.