laravilt/support
A Laravel support package offering reusable helpers, utilities, and foundational components for common development tasks. It streamlines everyday PHP and Laravel workflows, helping keep application code cleaner, more consistent, and easier to maintain.
Architecture fit. laravilt/support is a Laravel support package that pairs PHP-side helpers with a publishable frontend component layer. v1.1.0 materially widens that layer: React support is added alongside the existing Vue implementation, and the Vue foundation fixes from React are ported across, with Modal now honouring closeOnBackdrop. For a Laravel app already using Inertia + Vue or Inertia + React, this is a good architectural fit: one package covers shared backend utilities and consistent UI primitives across either frontend. For Blade/Livewire-only estates, the React/Vue surface is dead weight, and the value proposition reduces to the PHP helpers alone.
Integration feasibility. Standard Composer install with package auto-discovery, plus vendor:publish for config and frontend assets. The React addition likely introduces a second publish tag or asset namespace, so integration is not purely composer require — teams will need to confirm publish tags, Vite entry points, and peer dependencies (React version, Inertia version) before adopting. Laravel 13 compatibility is forward-looking: Laravel 13 is not yet a stable target, so the constraint is probably validated against a dev branch or widened constraint rather than a GA framework. That is fine for evaluation but should not be read as production-proven.
Technical risk.
Modal now honours closeOnBackdrop. If the previous behaviour was "always close on backdrop," any app relying on that will see different dismissal behaviour after upgrade — a user-facing change shipped under a semver-minor. This is the single highest-risk item in the release.actions/checkout, setup-node, action-gh-release, fetch-metadata). These are low-risk but inflate the changelog and obscure the two substantive PRs.Key questions.
closeOnBackdrop, and did it change from v1.0.5? Is there a migration note for consumers relying on the old dismissal behaviour?dev-master?--force, and will that overwrite local customisations?Stack fit. Best fit: Laravel 10–13 applications using Inertia with Vue 3 or React 18+, built through Vite. Acceptable fit: Laravel apps using only the PHP-side helpers. Poor fit: Blade/Livewire-only apps, or teams on Vue 2 or older React versions where peer constraints will conflict.
Migration path. Treat this as a patch-to-minor upgrade with one behavioural check:
composer update laravilt/support in a branch.--force is required and whether local component overrides exist).Modal usages and audit any that depended on backdrop-click dismissal.For React adopters, this is effectively a new integration rather than an upgrade: add the React publish tag, wire the Vite entry, and validate peer dependencies rather than assuming drop-in parity.
Compatibility. Verify PHP constraint, Laravel version constraint (including whether Laravel 13 is allowed via a widened range), Node/Vite versions for the React build, and React/Inertia peer ranges. Check that the package's React dependency does not force a duplicate React copy in the bundle.
Sequencing. Upgrade Vue consumers first — the Vue changes are corrective and lower-risk once the modal behaviour is confirmed. Schedule React adoption as a separate, later workstream with its own spike and test pass, since it introduces a new framework path rather than modifying an existing one. Do not combine the Laravel 13 constraint bump with a production rollout until Laravel 13 reaches GA and the package has a tagged release validated against it.
Maintenance. The package now maintains two frontend implementations plus a PHP layer. Every UI fix must be applied twice, and PR 17 ("port React foundation fixes to Vue") shows that drift has already occurred once. Expect ongoing parity work. Dependabot activity is healthy but also means frequent low-value releases; pinning to minor versions with scheduled review is preferable to chasing each tag.
Support. Single primary maintainer plus a first-time contributor is a bus-factor concern for a package sitting in the UI critical path. Internal documentation should record the pinned version, any locally overridden published components, and the modal behaviour decision, so an upgrade does not depend on tribal knowledge. If React support is adopted, the team needs a React-capable owner; a Vue-only team will struggle to debug React-side issues.
Scaling. Runtime scaling is not a concern — these are UI primitives and helpers. The scaling cost is organisational: two framework tracks, doubled regression surface, and bundle-size growth if both component sets are published into one app.
Failure modes.
Ramp-up. Low for backend-only consumption — one Composer line and a config publish. Moderate for Vue consumers — mostly asset re-publish plus a modal behaviour audit. High for React adoption: new publish tags, Vite wiring, peer dependency validation, and a team unfamiliar with the React implementation. Budget a short spike before committing, and keep the upgrade to v1.1.0 decoupled from React adoption so a modal regression does not block the React evaluation.
How can I help you explore Laravel packages today?