Schemas Laravel Package

Getting Started

laravilt/schemas is a schema-definition layer for Laravel: you describe UI (forms, layouts, wizards) as PHP schema objects, and the package renders them through its bundled frontend components. v1.1.0 is the first release worth adopting for new projects because it adds React support and Laravel 13 compatibility — before this, you were effectively locked to the Vue side and Laravel ≤12.

Minimal steps:

1. Require the package and publish its assets/config (php artisan vendor:publish for the laravilt/schemas tag) so the frontend components and Tailwind classes resolve.
2. Decide your frontend: Vue or React. v1.1.0 is the first release where React is a real option — pick one deliberately, since the component imports differ.
3. Build the smallest possible schema first: a single Schema with a couple of fields, rendered on one page. Do not start with the Wizard.
4. Only after that, add a Wizard and a layout container.

Where to look first: the schema base class and the Wizard class on the PHP side, then the corresponding frontend entry points in the package's JS source. The Wizard is the highest-value and highest-complexity piece, so read its source before you use it.

First use case: a multi-step onboarding or settings form. That exercises schema definition, layout rendering, reactive updates, and localization — the four areas this release touched.

Implementation Patterns

Schema-as-PHP-object. Define fields and layout in PHP, keep the frontend dumb. This keeps validation rules, labels, and structure colocated and testable. Resist the urge to hand-write the JSX/template; you lose the point of the package.

Wizard for multi-step flows. The Wizard is the natural fit for anything with steps and per-step validation. Structure it as one wizard schema with step schemas, not N separate pages with your own state — you get the step navigation, reactive state, and localization for free.

Localization via the support composable. As of v1.1.0 the Wizard imports its localization composable from support rather than defining it locally (PR #13). Follow that pattern in your own components: consume the shared composable instead of rolling a per-component translation helper, otherwise your wizard labels and your app labels will drift.

Reactive updates. v1.1.0 fixes reactive updates in Schema (PR #16). If you have dependent fields (country → region, plan → price), this is the release where that behaviour is reliable. Model dependencies by referencing sibling field state rather than wiring your own watchers — the package now handles the re-render.

Layout containers. Compose with layout primitives (sections, grids, tabs) rather than one flat field list. The v1.1.0 layout rendering fix means nested layouts now render as authored; if you previously worked around layout bugs with manual wrappers or CSS hacks, remove them before upgrading or you'll double up.

Tailwind. The package ships Tailwind classes. Ensure your Tailwind content config includes the package's compiled views/components, or the classes will be purged in production while working fine in dev. This is the single most common "works locally, broken in prod" cause with packages like this.

React or Vue, not both. Keep one adapter path in your app. If you migrate to React, do it per-page rather than mixing adapters in one schema tree.

Gotchas and Tips

• Minimum viable version is v1.1.0. If you're on ≤v1.0.6, you're missing the layout rendering, reactive update, and Tailwind fixes in PR #16 — those are correctness fixes, not polish. Upgrade before building anything with nested layouts, or you'll build workarounds you then have to unwind.
• Wizard localization changed in v1.1.0. The composable now comes from support. If you had extended or overridden the wizard's translation behaviour in v1.0.x, re-check it after upgrading; a local import shadowing the shared one is the likely breakage.
• Laravel 13 compatibility is new. Pin your Laravel constraint deliberately. If you're on Laravel 13, v1.1.0 is your floor. If you're on 12, this release is safe but not required for that reason alone.
• React support is new, so it's the least battle-tested surface. The PRs this cycle fixed Vue-side rendering and reactivity. If you need stability today and have no strong reason, Vue is the more-travelled path; if you're React-only, budget time for rough edges and keep a minimal reproduction handy when filing issues.
• Tailwind purging in production — see above. Check the production build early, not at deploy time.
• Debugging rendering issues: reduce to a single field in a single container before suspecting the package. Layout bugs and reactive bugs look identical from a complex schema. Then add one level of nesting at a time.
• Dependabot noise in the changelog. Most of the listed changes are CI action bumps (actions/checkout, softprops/action-gh-release, dependabot/fetch-metadata, actions/setup-node). They're irrelevant to your app — only PRs #13, #15, and #16 are functional. Read the changelog with that filter to avoid over-estimating the risk of upgrading.
• Extension points: keep your own schema subclasses thin. Overriding layout rendering or the wizard's step logic is where you'll fight future releases — the package is moving fast (1.0.6 → 1.1.0 adding an entire frontend framework), so prefer composing package primitives over subclassing internals.