Ux Collection Js Laravel Package

Technical Evaluation

What the package actually is. tienvx/ux-collection-js is a third-party split of Symfony UX "Collection" — the Stimulus controller that powers dynamic add/remove rows in Symfony form collections. The first finding for a Laravel/PHP evaluation is a premise mismatch: this is a Symfony UX package, not a Laravel package. It inherits Symfony UX conventions (Twig helpers, Flex recipe, symfony/stimulus-bridge, bundle registration) that have no counterpart in a Laravel application. Only the JavaScript asset is potentially portable; the PHP half is effectively inert in our stack.

Architecture fit. Poor as a dependency, plausible as a reference implementation.

Integration feasibility. Low-to-moderate. A Laravel team could consume the controller by copying or npm-vendoring the JS and wiring it to a Blade partial, but at that point we have reimplemented the integration and own it — the package adds no leverage. The Composer path is not viable.

Technical risk.

• Staleness (high): last release 2022-07-17, roughly three Symfony UX minor versions behind. Symfony UX 3.x changed Stimulus bootstrap (startStimulusApp, @symfony/stimulus-bridge registration, ControllerFactory) — the 2022 build is likely broken against current asset tooling.
• Bus factor (high): 13 stars, one maintainer, one of a large family of personally maintained *-js splits; no evidence of a support commitment.
• Supply chain / security (low): MIT, tiny client-side surface, no server-side execution, no known CVEs. The risk is abandonment, not exploitation.
• Reversibility (favorable): the functionality is a few dozen lines of vanilla JS. Replacement cost is low, which materially offsets the staleness risk — but also removes the reason to depend on it.
• Scoring: 0.619 reflects a package that is technically coherent but weakly signaled — consistent with "usable as prior art, not as a dependency."

Key questions for the maintainer / spike.

1. Is this a fork or a reimplementation of upstream Symfony UX Collection, and which upstream version is tracked?
2. Does the package publish a standalone ESM artifact usable without Twig/Encore, and under what entry point?
3. What is the compatibility matrix for Stimulus 3.x and Symfony UX 3.x, and is a 3.x release planned?
4. Are there consumers beyond the author, and what is the issue-response history?
5. Does it handle the hard parts of collection UX (prototype placeholders, index renumbering, nested collections, deletion flags) or only naive add/remove?

Integration Approach

Stack fit and recommendation. Do not add this as a runtime dependency. Treat it as a design reference and, if the collection UX matches our needs, port the controller into our own first-party front-end code. Our target stack is Blade + Vite + Livewire/Alpine; Symfony UX is a foreign idiom and adopting it for one widget imports a second component model into the codebase.

Viable options, ranked.

1. Livewire (preferred): native dynamic collection handling with server round-trips; no new JS dependency, no Stimulus. Cost is latency on add/remove; acceptable for admin-style forms.
2. Alpine.js (preferred for client-only forms): small, already common in Laravel front ends; a collection controller is ~50 lines and fully ours.
3. Port the Stimulus controller (fallback): only if we already run Stimulus. Vendor the file under resources/js/vendors/, pin to a commit SHA, add a provenance header and a link to the upstream repo.
4. Composer dependency (not recommended): would require Flex-style bundle wiring and leaves an unused Symfony subtree in vendor/.

Migration path. There is nothing to migrate from; this is greenfield adoption. The only migration concern is the reverse — if a team has already copied the controller, define an internal package path so it can be swapped for a first-party implementation without touching templates.

Compatibility constraints to verify in a spike.

• Stimulus version (2.x vs 3.x) and controller registration format.
• Module format: ESM vs UMD; behavior under Vite/Rollup vs Encore.
• Whether the JS references Twig-rendered prototype markup contracts (data attributes, data-collection-* names) that must be reproduced in Blade.
• Browser baseline from 2022 (likely fine, but confirm no transpile gaps).

Sequencing.

1. Spike (0.5–1 day): read the controller source, confirm prototype/index-renumbering behavior, record the data-attribute contract.
2. Decision gate (same week): if Livewire or Alpine satisfies the UX, close out the evaluation and archive findings.
3. Port (2–3 days) only if gate fails: reimplement in our idiom, attribute the MIT source, add unit tests for add/remove/renumber/nested.
4. No production dependency on the Composer package at any stage.

Operational Impact

Maintenance. Ownership lands entirely with us either way. As a dependency, we would carry an unmaintained 2022 artifact with no upgrade path and no upstream to escalate to. As a port, we carry ~50 lines we control. The port is strictly cheaper over a 12-month horizon; dependency adoption here is negative-value maintenance.

Support. None commercial, single maintainer, no SLA. Internal support burden falls on whichever team owns the form layer. Because the code is client-side only, failures surface as UI breakage in forms — high-visibility, moderate-severity, easy to hotfix.

Scaling. No backend or infrastructure scaling impact — no server-side execution, no DB, no queue. The only scale dimension is form complexity (row counts, nested collections), where the original implementation's DOM cloning approach may degrade on very large collections. Validate against our worst-case form (target: 200+ rows, 2 levels of nesting) rather than assuming.

Failure modes.

Ramp-up. Low for JS developers: Stimulus is a small API and the controller is short. The real cost is conceptual, not technical — a Laravel team must learn Symfony UX conventions to read the upstream docs, then discard most of them. Budget half a day of orientation, and expect the port to take longer than the "copy the file" estimate once markup contracts and nested-collection behavior are covered.

Bottom line for the roadmap. Score 0.619, 13 stars, and a three-year release gap do not support a production dependency, and the Symfony-vs-Laravel mismatch makes the Composer route a non-starter. Use the repository as prior art for a first-party Livewire or Alpine implementation, record the decision in an ADR, and revisit only if the maintainer ships a 3.x release with a documented, framework-agnostic ESM entry point.