Ux Bundle Laravel Package

Technical Evaluation

Architecture fit. The decisive fact for a TPM is that kibatic/ux-bundle is a Symfony bundle, not a Laravel package. It presumes Symfony's bundle registration (config/bundles.php), Symfony UX (Turbo/Stimulus), and either AssetMapper or Webpack Encore with a Flex-style asset pipeline. None of that exists in a Laravel application. Laravel has no bundle loader, no debug:config-style bundle introspection, and its frontend story (Blade + Livewire + Vite, or Inertia) is architecturally separate from Symfony UX. On a Laravel stack this is not integrable — it is a pattern reference at best. Fit against a Symfony estate would be plausible but unproven, since there is no community evidence of anyone running it.

Integration feasibility. For a Symfony target the mechanics are routine: Composer install, optional Flex recipe, manual bundles.php registration, asset pipeline wiring, container/config validation via console commands. There is no runtime infrastructure, no data-plane component, no native extension. The feasibility problem is therefore not technical but organisational and evidentiary: we would be the first integrator of a package with zero stars and zero dependents, meaning no field-tested upgrade path, no known incompatibility list, and no one else to absorb the discovery cost. For Laravel, feasibility is zero without a port, and a port means either extracting the Twig helpers into Blade directives or rebuilding the opinionated defaults from scratch — at which point we are no longer adopting the package.

Technical risk. High, and concentrated in sustainability rather than code quality. The package is small, MIT, and touches only the rendering/asset layer, so the blast radius is bounded — a failure breaks UI conveniences, not auth, payments, or persistence. But the adoption signal is the worst possible: single maintainer, no dependents, no issue history to inspect, and a future-dated release (2026-06-11) that cannot be trusted as a stability marker without checking whether it is a real tag, a pre-release, or a scoring artifact. The highest-severity risk is framework coupling: UX bundles track Symfony minors closely, so a stalled maintainer can pin the whole application to an unsupported Symfony version, which becomes a security-patching and compliance problem over time. MIT makes forking cheap in licence terms but expensive in engineering terms, because we would inherit a permanent upgrade-cadence obligation for a thin convenience layer.

Key questions.

1. Do we operate, or plan to operate, any Symfony application? If not, this should be reclassified off the Laravel roadmap immediately and the evaluation closed.
2. What does the bundle provide that upstream Symfony UX (Turbo, Stimulus, Twig components) does not? Is it a genuine gap-filler or a thin re-export that we could replicate in a few dozen lines?
3. Who is the maintainer of record at Kibatic, what is their stated Symfony version support window, and what is the release cadence over the last 12 months?
4. Is the 2026-06-11 release a real published tag with a changelog, or metadata noise? Can we pin an exact version and inspect the diff?
5. What is the exit cost — can we strip the bundle and fall back to vanilla Symfony UX inside a single sprint without touching product features?
6. If we build our own equivalent (a small internal UI helper package), what would it cost, and is that cheaper over 24 months than owning a fork?

Integration Approach

Stack fit. Currently negative for Laravel and merely conditional for Symfony. There is no Laravel service provider, facade, config-publishing step, or Blade integration, so no integration work on our primary stack can succeed. The correct TPM action is a routing decision, not an engineering ticket: hand this to the Symfony platform owner if one exists, and otherwise close it. Treat the item as a pattern library input — read the source to harvest ideas for our own Blade/Livewire helpers — rather than a dependency.

Migration path. There is no migration; this is greenfield adoption in a Symfony-only scenario. If pursued there, the sequence is: Composer install → Flex recipe or manual KibaticUxBundle registration in config/bundles.php → asset pipeline wiring (AssetMapper preferred on Symfony 7, Encore for legacy) → adopt feature-by-feature behind a single base layout so rollback is a configuration toggle rather than a rewrite. The governance rule to enforce: adopt as a leaf dependency, never as a foundation. Nothing in the critical rendering path may depend on it in a way that requires code changes to remove.

Compatibility. Unknown and must be established before any commitment. We need an explicit Symfony version matrix, the PHP floor, AssetMapper vs. Encore support, and tolerance for our existing Stimulus controller conventions. With zero dependents there is no field evidence of compatibility — we would be generating the first data point. On the Laravel side, compatibility is not a question worth investigating; the answer is "no."

Sequencing. If a Symfony target is real, sequence as: (1) a time-boxed spike of three engineer-days against a disposable Symfony skeleton, explicitly answering "what does this give us over upstream Symfony UX?"; (2) a written comparison against vanilla Symfony UX and against a hand-rolled internal helper; (3) only then a single low-traffic internal app as a canary; (4) re-evaluate after one Symfony minor upgrade cycle to see whether the bundle kept pace. Gate 1 is a kill gate. If the spike shows a thin re-export, stop and use upstream. For the Laravel roadmap, the sequencing is simply: no slot, no milestone, no dependency.

Roadmap implication. The TPM-level value here is defensive, not additive. Recording the decision — "evaluated, rejected for Laravel, routed to Symfony owner, revisit at ≥100 dependents and a 12-month active cadence" — prevents a second engineer from re-running this evaluation next quarter. That decision record is the deliverable.

Operational Impact

Maintenance. The dominant cost and the reason not to adopt. With no community, no dependents, and a single maintainer, we should plan on being the maintainers in practice: tracking Symfony releases, patching incompatibilities, and likely forking within 12–24 months. That is an ongoing engineering line item, not a one-time integration. A defensible estimate is a few days per Symfony minor release for validation, plus unplanned work whenever upstream UX changes land. On a Laravel stack the maintenance cost is different but no better: porting the ideas means owning bespoke Blade/Livewire helpers indefinitely with no upstream to harvest from.

Support. None observable — no SLA, no support contract, no security policy, no issue-triage history to assess responsiveness. Internal support would fall to whichever team owns the host application. Security exposure is low because the package sits in the render/asset layer, but availability exposure is real: a stalled maintainer blocks framework upgrades, which over time becomes a compliance and patching concern that outranks the convenience gained.

Scaling. Technically trivial — it is a rendering and asset concern with no data, concurrency, or throughput characteristics. The scaling problem is organisational: every additional Symfony app that adopts it multiplies the maintenance surface, and the institutional knowledge of its quirks will concentrate in one or two engineers. Cap adoption at a single canary app until the maintainer relationship is proven, and do not let it enter an "approved toolkit" list on the strength of a spike.

Failure modes.

• Ecosystem mismatch (highest likelihood on our stack): someone attempts Laravel integration, spends a sprint discovering Symfony bundle semantics do not transfer, and the work is written off.
• Silent divergence: upstream Symfony UX moves, the bundle stagnates, and subtle rendering/asset bugs appear after a framework upgrade with no upstream fix.
• Upgrade blockade: the bundle pins a Symfony version, freezing the application on an unsupported minor.
• Abandonment: repository archived; we inherit a fork with no upstream and no exit ramp.
• Metadata trap: adopting on the basis of a future-dated release without verifying the actual tag, changelog, and API stability.
• Bounded blast radius: failures manifest in UI convenience, not transactions or auth — which is the one argument for a canary-only trial and the reason this is a "no" rather than an "urgent no."

Ramp-up. Low technical ramp-up — a Symfony developer is productive in hours, and a Laravel developer would be productive in minutes if a Blade port existed. Organisational ramp-up is the real cost: someone must own the vendor-risk assessment, the fork contingency, the upgrade cadence, and the decision record. That ownership overhead is disproportionate to the value delivered by a 0-star, 0-dependent, opportunity-score-23 package.

TPM recommendation. Do not adopt; close the Laravel evaluation. Reclassify as a Symfony-ecosystem item and route it to the Symfony platform owner if one exists, otherwise archive the decision with a re-evaluation trigger (e.g. ≥100 dependents plus a demonstrated 12-month release cadence). If a genuine Symfony UX boilerplate gap is identified, fund the three-day spike to prove the bundle beats upstream Symfony UX before any dependency is taken. On the Laravel roadmap, the correct use of this package is as a source of ideas for an in-house Blade/Livewire helper layer — and the correct deliverable from this assessment is a written record that the question was asked and answered, so it is not asked again.