pushery/wirekit
A free, open-source UI component library for Laravel Livewire, built on Tailwind CSS v4 and Alpine.js. Forms, navigation, overlays, layout, marketing and data display components — themeable, accessible and dark-mode ready.
Architecture fit. WireKit is not a general-purpose UI library — it is a stack-committed Blade component layer. It only makes sense for a product already standardized on Laravel + Livewire, and it hard-pins the entire modern edge of that stack: PHP 8.4+, Laravel 12+/13+, Livewire 4+, Tailwind CSS v4, Alpine.js. That is a narrow aperture. If our runtime is PHP 8.2/8.3, Laravel 10/11, Livewire 3, or Tailwind 3, WireKit is not an incremental add — it is a forcing function for a multi-major upgrade across four layers simultaneously. The value proposition is real where it fits: ~150 components across forms, data display, overlays, navigation, layout, typography, and marketing, with a 4-level theming model built on --color-wk-* CSS variables, dark-mode by default, and accessibility treated as a first-class contract. It composes at the Blade layer (<x-wirekit::button intent="danger">), so nothing leaks into domain code — the coupling is presentation-only, which is the right kind of coupling.
Integration feasibility. Mechanically trivial: composer require, two Blade directives, and one @source line in app.css to make Tailwind v4 scan the vendor Blade views. The Tailwind v4 CSS-first model (no tailwind.config.js) means there is no config-file merge to manage. The @source directive is also the main sharp edge — it is an opaque string path into vendor/, and a package layout change or a vendor prune silently breaks styling with no build error. That is a one-line setup with a non-obvious failure signature, and it should be treated as an infrastructure change requiring a regression check, not a convenience import.
Technical risk (ranked).
pushery). There is no third-party adoption evidence and no community to absorb abandonment. For a design-system-layer dependency — the hardest thing in a codebase to rip out — this is the dominant risk.NOASSERTION. That discrepancy must be closed by legal before adoption — and separately, the optional ApexCharts adapter is non-MIT (free only under $2M USD revenue, commercial license above). Shipping that adapter without a revenue check is a latent compliance finding.aria-label was landing on a wrapper instead of the role-bearing element across otp-input, rating, tags-input, and file-upload. That is exactly the class of defect that surfaces in an audit. Adopting WireKit means inheriting its a11y posture with no indemnity; it needs to be in our own test plan..cursor/rules because prop names, tokens, and composition examples had drifted from the real components. That is honest maintenance, but it demonstrates the failure mode: AI-assisted and doc-driven authoring can confidently generate wrong markup.Key questions.
NOASSERTION discrepancy in writing? Are we above the ApexCharts revenue threshold?Stack fit. Treat WireKit as fit-only-if-already-aligned. Greenfield Laravel 12/13 + Livewire 4 + Tailwind 4 is the natural home; there the setup cost is roughly an afternoon and the payoff is large. On any older stack, the honest framing to stakeholders is that adopting WireKit means adopting the entire target stack — the UI library is the last step of that program, never the justification for it.
Migration path. Prefer greenfield surfaces and new vertical slices over retrofit. For brownfield, do not attempt a big-bang component swap: Tailwind v4 and Tailwind 3 do not coexist cleanly, so the realistic path is to migrate the host app to Tailwind 4 first under the existing component set, stabilize, then introduce WireKit incrementally behind a component allowlist. Where a legacy design system must persist temporarily, isolate WireKit-rendered surfaces at the layout boundary rather than mixing both inside one view.
Compatibility. Three compatibility contracts need explicit verification, not assumption: (1) Tailwind v4 @source scanning — confirm the vendor path resolves in CI and after composer install --no-dev; (2) Alpine.js — WireKit's interactivity is Alpine-driven, so audit for directive/plugin collisions with existing Alpine usage (x-data nesting, x-cloak, Alpine plugins loaded more than once); (3) Livewire 4 — verify wire:model binding and lifecycle behavior on the form-heavy components (combobox, date-picker, multi-select, filter-builder) before committing to them, since those carry the most client-state complexity.
Sequencing.
wirekit:install, theme token layer, build ~10 representative components including at least two complex ones (a data table, a form widget) plus one overlay. Success criteria: builds green in CI, dark mode correct, keyboard/screen-reader pass on the sampled set.--color-wk-*, and how far we customize (CSS variables → published views). Committing to published views is a fork-like maintenance cost; decide deliberately, not by drift.Maintenance. Budget an ongoing owner, not a one-time install. The cadence visible in the changelog is healthy (2.9.0 minor, 2.8.1 patch) but the content of each release includes documentation and AI-tooling corrections, meaning upgrades are not purely passive. Pin to a minor version, upgrade on a scheduled cadence, and re-run wirekit:boost-skills / refresh .wirekit-schema.json after every bump — stale generated context is how AI-assisted authoring starts emitting wrong props. Regenerate and diff the component manifest between versions to see breaking surface before it hits a feature branch.
Support. There is no SLA, no commercial backing, and no support channel beyond docs.wirekit.app and the changelog. Internal ownership must be explicit: one named engineer accountable for the dependency, with a documented escalation path that ends in "publish views and fork." Note the asymmetry — the AI tooling (wirekit:list, wirekit:show, wirekit:icons, the read-only local MCP server, AGENTS.md, Cursor rules, Boost skills) is genuinely best-in-class for onboarding and is version-matched to the installed package, so it cannot drift the way handwritten docs did. That is a real, quantifiable ramp-up saving that partly offsets the support vacuum.
Scaling. Runtime footprint is light — Blade output plus Alpine, no JS framework. The scaling cost lands in the CSS build: @source makes Tailwind scan vendor Blade, so stylesheet size grows with breadth of component adoption and cold build times lengthen. Component breadth is both the asset and the hazard: a 150-component catalog invites teams to adopt surface area they cannot maintain or audit. Gate adoption with an allowlist.
Failure modes to instrument.
--no-dev install breaks @source; no error, just unstyled pages. Add a smoke assertion on a known component's computed styles in CI.--color-wk-* names and brand overrides stop applying. Snapshot the token layer.x-data producing dead interactivity in overlays and pickers.optimistic="..." needs a deliberate rejected-path test, and the bundle must not be loaded app-wide "just in case."aria-label class of bug. Add per-component a11y assertions to the adoption checklist rather than trusting the "accessible by default" claim.Ramp-up. Low for anyone fluent in Blade + Tailwind + Alpine; the component API is declarative and the discovery CLI plus MCP server compress the learning curve meaningfully — a mid-level engineer should be productive inside a sprint. The steeper learning is the theming discipline: teams must internalize the --color-wk-* token system and resist ad-hoc class overrides, or the "no utility-class soup" promise dissolves within two sprints. Allocate a short internal enablement session on tokens and the allowlist policy; that, not the install, is where adoption succeeds or fails.
How can I help you explore Laravel packages today?