Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Support Laravel Package

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.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

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.

  • Behavioural change in a minor release. 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.
  • New React surface area. React support is a first contribution from a new contributor, with "foundation fixes" ported to Vue afterwards. That sequencing suggests the React implementation is the newer, less battle-tested path, and parity between the two frameworks is asserted rather than proven.
  • Laravel 13 claim. Compatibility is declared ahead of framework GA; dependency constraints may pull dev-stability packages or mask incompatibilities that only appear on the final release.
  • Dependabot noise. Five of the seven changes are CI action bumps (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.

  1. What is the default value of closeOnBackdrop, and did it change from v1.0.5? Is there a migration note for consumers relying on the old dismissal behaviour?
  2. Is the React implementation at feature parity with Vue, and is it covered by equivalent tests?
  3. Which Laravel 13 constraint is declared, and is it tested against a tagged release or dev-master?
  4. Are React peer dependencies pinned to a range compatible with common Inertia/React setups?
  5. Do published Vue assets need to be re-published with --force, and will that overwrite local customisations?

Integration Approach

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:

  1. composer update laravilt/support in a branch.
  2. Re-publish frontend assets to pick up the ported Vue fixes (confirm whether --force is required and whether local component overrides exist).
  3. Grep for Modal usages and audit any that depended on backdrop-click dismissal.
  4. Rebuild frontend bundles and run the app's JS test suite.
  5. Deploy to staging, manually verify modal open/close/backdrop/escape behaviour, then promote.

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.

Operational Impact

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.

  • Modal backdrop regression: users unable to dismiss modals, or modals closing unexpectedly on stray clicks. Highest-impact, most likely failure.
  • Framework parity bugs: a fix landing in React but not Vue, or vice versa.
  • Asset re-publish overwriting local customisations of published components.
  • Laravel 13 constraint resolving to unstable dependencies in CI or production.
  • Peer dependency conflict producing a duplicate React instance and runtime hook errors.

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.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
cgv/localized-resource