Ux React Laravel Package

Technical Evaluation

Framework mismatch (primary finding). The release under review is symfony/ux-react v3.6.0 — a Symfony UX package, not a Laravel package. It ships no Laravel service provider, no facade, no Blade directives, and no Vite/Mix integration. Its architecture assumes the Symfony stack: AssetMapper for asset resolution, StimulusBundle for controller registration, Twig for templating, and PHP attributes/DI for wiring. In a Laravel application those responsibilities are already owned by Vite + laravel-vite-plugin, Blade, and the service container. Adopting this package therefore means importing a parallel frontend toolchain rather than extending the existing one.

Integration feasibility. Composer-installable and PHP 8.x-compatible, so installation is mechanically possible. Functional use is not: rendering React components through this package requires symfony/asset-mapper, symfony/stimulus-bundle, and Twig, none of which are native to Laravel. A bespoke glue layer (Twig bridge or an AssetMapper-in-Laravel shim) would have to be written and owned internally, which converts a "drop-in package" into a custom integration project.

Technical risk — the actionable item in this release. bug #3919 Conflict with symfony/asset-mapper 8.2 and later is the only change with dependency-resolution consequences. The package now declares an explicit conflict against symfony/asset-mapper >= 8.2, meaning Composer will either refuse to install or force a downgrade of asset-mapper. For any team already on asset-mapper 8.2+, this release is a hard blocker until the conflict is lifted. The other two entries (#4086 tooling dependency bump, #3907 README version placeholder) are non-functional and carry no integration risk.

Key questions.

1. Is the target application actually Laravel, or is this release being evaluated against a Symfony codebase? The package/framework pairing in the request appears to be a mismatch and should be confirmed before effort is spent.
2. If Laravel: what capability does symfony/ux-react provide that Inertia + React, Livewire, or a plain Vite React entrypoint does not already provide with less glue?
3. Which symfony/asset-mapper version is pinned in our lockfile today, and would this conflict force a downgrade?
4. Is the asset-mapper 8.2 conflict expected to be temporary (i.e., will it be resolved in 3.6.x), or is it a durable constraint?
5. Which Symfony minor branch does ux-react 3.x target, and is that branch still receiving security fixes?

Integration Approach

Stack fit: poor for Laravel, strong for Symfony. If the estate is Laravel, the idiomatic path to React is Vite + Inertia (or a standalone Vite entrypoint); the idiomatic path to reactive server-driven UI is Livewire. symfony/ux-react duplicates those responsibilities while adding AssetMapper, Stimulus, and Twig as transitive obligations. If the estate is Symfony, the package fits cleanly and this release is routine.

Migration path. For a greenfield Laravel app: no migration path is warranted — do not adopt. For a Laravel app with an inherited Symfony UX React surface (e.g., post-acquisition or a shared component library), the viable path is isolation rather than embedding: run the Symfony UX surface as a separate service or pre-built bundle, consume its output over HTTP or as compiled static assets, and keep AssetMapper/Twig out of the Laravel runtime. Do not attempt to co-host both asset pipelines in one application.

Compatibility. Three constraints to verify before any decision: (a) the asset-mapper < 8.2 conflict introduced in this release; (b) the PHP version floor declared in composer.json; (c) Twig and StimulusBundle version ranges, which drift independently of this package. The conflict in (a) is the one that will surface first in CI, because it fails at composer install rather than at runtime.

Sequencing.

1. Confirm framework target and intended use case — this gate determines whether steps 2–5 are relevant at all.
2. Run a throwaway composer require symfony/ux-react:^3.6 against a scratch Laravel app to observe the actual resolution outcome and record whether asset-mapper is downgraded or the install aborts.
3. If proceeding, pin symfony/asset-mapper below 8.2 and commit the lockfile; document the pin and its reason next to the dependency.
4. Pilot on a single non-critical UI surface, with the explicit success criterion being "no second asset pipeline in production."
5. Re-evaluate against Inertia/Livewire on cost-to-first-value before expanding scope.

Operational Impact

Maintenance. Upstream stewardship is strong — Symfony maintains this package with regular minor releases (3.5 → 3.6 arrived quickly, with routine tooling bumps). The maintenance burden lands on us, however, and it is the glue code, not the package: any Twig/AssetMapper/Stimulus bridge written to make this work in Laravel is entirely internally owned, with no upstream tests, no upstream docs, and no upstream fixes.

Support. Upstream issue triage is Symfony-shaped. Laravel-specific failure modes (Blade/Twig coexistence, Vite and AssetMapper both claiming the manifest, service container divergence) will not be recognized as in-scope bugs. Recourse is internal expertise plus the smaller symfony/ux community, which is materially thinner than the Inertia or Livewire ecosystems for Laravel questions.

Scaling. AssetMapper's importmap-based approach is workable but less mature than Vite for large React single-page applications — notably around hot-module-reload ergonomics, code-splitting, and build-time optimization. For a growing React surface, this becomes a build-performance and developer-experience ceiling rather than a hard wall.

Failure modes.

• Dependency deadlock (highest likelihood, already realized): the asset-mapper >= 8.2 conflict blocks installs and upgrades. This is the concrete operational risk introduced by v3.6.0.
• Blocked security upgrades: pinning asset-mapper < 8.2 means future asset-mapper security patches cannot be taken until upstream lifts the conflict.
• Dual-pipeline drift: Vite and AssetMapper both authoritative for assets produces non-deterministic builds that are painful to debug.
• Glue-code abandonment: the internal bridge outlives the original author's context and becomes unmaintained.
• Version drift: Twig/StimulusBundle advancing past the ranges this package tolerates.

Ramp-up. High for a Laravel team — Twig, Stimulus, AssetMapper, and Symfony DI conventions are all new surface area for developers fluent in Blade and Vite, and none of that learning transfers back to the core product. Low for a Symfony-fluent team. On a mixed team this creates a knowledge silo around a component that a small number of people understand, which is a continuity risk independent of the technology's merits.

Assessment of this release specifically. v3.6.0 is a minor release with one materially relevant change: the asset-mapper 8.2 conflict. It introduces no new features and no deprecations, and it does not change the strategic conclusion. It does add a concrete, near-term dependency constraint that should be recorded in the lockfile rationale if the package is already in use — and it should be treated as a signal to confirm whether the underlying package/framework pairing was ever correct.