Wireui Laravel Package

Product Decisions This Supports

• Build vs. buy for the UI layer. WireUI-style packages answer a recurring roadmap question: do we hand-roll buttons, modals, notifications, dropdowns, date pickers, and form controls for every Laravel/Livewire surface, or do we adopt a component library and spend the saved sprints on product differentiation? This package is the "adopt" option, so it directly shapes sprint allocation for any Livewire-based UI work.
• Time-to-market for admin, internal, and back-office surfaces. The highest-leverage use cases are the ones that are high-volume but low-differentiation: admin panels, settings pages, CRUD screens, ops dashboards, customer portals. These are also the screens where a mature component set converts weeks of front-end scaffolding into days.
• Feature scope for MVP and early-access releases. Adopting a batteries-included component kit lets a small team ship modal-driven flows, toast notifications, and inline validation feedback without pulling dedicated front-end capacity — a real input to "can we hit this launch date with the current headcount?"
• Design-system and theming positioning. Tailwind-native, configurable components let you pick between (a) a house style built on top of the library's primitives, or (b) out-of-the-box defaults to de-risk an early launch. This is a product decision about perceived polish versus engineering cost, not just a technical one.
• Dependency risk as a roadmap input. A fork with effectively zero visible stars or dependents is a measurable risk to the maintenance budget and to the credibility of any "we'll support this for three years" commitment. That risk belongs in the roadmap as explicit capacity, not as an unspoken assumption.
• Portability and exit-cost planning. Any decision here should be paired with a judgment on how cheaply the components could be replaced — which informs whether this is a safe bet for a time-boxed internal tool versus a poor bet for a long-lived, white-labeled customer-facing product.

When to Consider This Package

Adopt when:

• The stack is already Laravel + Livewire + Tailwind CSS, ideally Livewire 3, with Alpine.js available. Outside that stack the package delivers little and costs integration effort.
• The near-term roadmap is dominated by internal or admin-facing UI where consistency, speed, and reasonable defaults matter more than pixel-level brand differentiation.
• The team is small and back end–heavy, without dedicated front-end engineers to build and maintain a component library in-house.
• You need specific, well-understood components — modals, slide-overs, notifications, dropdowns, date/time pickers, form controls with validation states — and you want them to behave consistently rather than being reimplemented per feature.
• You are willing and able to vendor the code into your repository (Composer path/VCS or a copied namespace) so you control upgrades and can patch locally. A fork is only safe when you treat it as source you own.
• You have a plausible replacement path if the package stalls — either upstream WireUI, a commercial Livewire component suite, or your own extracted components.

Look elsewhere when:

• The front end is React/Vue/Svelte, or Livewire is not in the stack. This is a hard stop.
• You need an enterprise-grade, accessibility-audited, formally maintained design system with a support contract, published release cadence, and a security-response process. Buy that; don't adopt an unaudited fork.
• The product is long-lived and customer-facing with strict brand and accessibility requirements — you will end up overriding so much that the savings evaporate, and you will own the fork.
• Supply-chain and security review is a hard gate. An unfamiliar fork with negligible adoption will not clear a typical third-party dependency policy without a documented exception.
• Upstream divergence is a concern. A fork's value tends to be features that upstream lacks; the cost is that upstream fixes, security patches, and Livewire/Tailwind major-version compatibility must be re-applied by hand. If nobody on the team can own that, don't start.
• Governance and continuity matter. With near-zero external adoption, the effective bus factor is one. If the maintainer stops, you are the maintainer.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a UI component library for our Laravel stack that lets the team assemble admin panels, forms, modals, and notification flows from ready-made pieces instead of building them from scratch. The business case is velocity on low-differentiation screens — realistically weeks of front-end effort saved per quarter for a small team — which we can redirect toward customer-facing features. The trade-off is straightforward: this particular package is an actively developed fork with essentially no visible adoption, so it carries maintenance risk. We mitigate that by vendoring it into our codebase, treating it as code we own, and budgeting a small ongoing allowance for upgrades and patches. My recommendation is to adopt it for internal and back-office surfaces where the risk is contained, and to hold it away from customer-facing or compliance-sensitive UI until it has more of a track record.

For engineering (the short version): Livewire 3 + Tailwind + Alpine component set — buttons, modals, slide-overs, notifications, dropdowns, date/time pickers, form controls with validation wiring. It's a fork of WireUI, so expect genuine improvements over upstream but also upstream divergence: we own merges, Livewire/Tailwind major-version compatibility, and security patching. Plan to vendor it (copy into packages/ or pin via a VCS/path repository) rather than depend on Packagist availability, pin an exact version, and wrap the components we actually use behind a thin internal layer so swapping out later isn't a rewrite. Before adopting, check: Livewire version compatibility, Tailwind config integration cost, bundle size and build-pipeline impact, whether the date picker and modal handle keyboard and focus management acceptably, and whether the license is compatible with our distribution model. If we can't commit an owner for upgrades, use upstream WireUI or a commercially supported suite instead.