Components Laravel Package

Product Decisions This Supports

• Build vs. buy for UI chrome: This is a Blade component kit (cards, widgets, description lists, links, sidebar items, tables, delete-confirmation buttons) that removes a recurring "who maintains our Blade partials?" cost. 2.2.0 adds render tests across the components, which is the signal that matters for a buy decision — you are inheriting a tested surface, not just markup.
• Feature scope for an internal admin/tooling surface or marketing shell: The component set is opinionated toward dashboards, detail views, and navigation. Use it to scope work on internal tools and CRUD-adjacent screens; it is not a general-purpose design system for a customer-facing brand surface.
• Upgrade scheduling: 2.2.0 changes rendered output. Props that were previously leaked as HTML attributes (title, route, icon, active) are now declared and withheld. Any screen relying on those attributes — the release explicitly calls out a card title that surfaced as a hover tooltip — will visibly change. This warrants a scheduled upgrade with a visual pass, not a silent patch bump.
• Design-system dependency decisions: The README now documents Tailwind 4, bundled Heroicons, required primary/info/success/danger color scales, and an app.owner config for the footer. Adopting this package is a commitment to that Tailwind version and palette contract. If your roadmap includes a Tailwind 4 migration, this package is now aligned rather than a blocker; if you are staying on Tailwind 3, that is a roadmap constraint to record.
• Configuration surface ownership: The footer now depends on app.owner. That is a small but real config contract — a value your team must own and set per environment, and a place brand/legal copy can drift if unowned.

When to Consider This Package

Adopt when:

• You are on Laravel and Blade, use Tailwind, and want consistent, tested primitives for admin/dashboard and detail-view screens rather than bespoke partials.
• You are on, or migrating to, Tailwind 4 — 2.2.0's documentation and bundled Heroicons are written against it.
• Your design tokens already map to the primary/info/success/danger scale naming, or you are willing to define them.
• You want a small, single-vendor component surface you can read end-to-end, and you value the presence of render tests as a maintenance signal.

Look elsewhere when:

• You need a themable, accessibility-audited, or broadly customizable design system. This is a focused internal component set, not a theming framework.
• You are pinned to Tailwind 3, cannot define the four color scales, or cannot accommodate the app.owner config.
• You need a component library with an explicit deprecation policy and semver guarantees on rendered markup. 2.2.0 is a minor version that changes rendered output (dropped HTML attributes, removed a redundant form.submit() on the delete confirmation). Treat minor bumps here as potentially visual-breaking and budget QA accordingly.
• You need React/Vue/Livewire-first components rather than server-rendered Blade partials.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small Blade component library to supply the standard UI pieces — cards, detail lists, sidebars, tables, delete confirmations — for internal tooling. It is low-cost to adopt and now ships with automated render tests, which lowers our maintenance exposure. The 2.2.0 release is a quality release: it stops leaking internal component configuration into the HTML (a card title was previously rendering as a browser tooltip), cleans up a delete-confirmation form, and documents its Tailwind 4 and brand-color requirements. The main decision it forces is a Tailwind 4 and palette-standardization commitment, plus a small config value (app.owner) for the footer.

For engineering: Upgrade to 2.2.0 with a visual regression pass, not a blind bump. Props on card.card, widget, descriptionList.item, links.external, links.internal, and sidebar.item are now declared, so title, route, icon, and active no longer emit as HTML attributes — check for any styling, selectors, or tooltips that depended on them. A redundant form.submit() was removed from the delete confirmation, and a table footer @endisset was fixed. Before upgrading, confirm Tailwind 4, the bundled Heroicons, the primary/info/success/danger color scales, and the app.owner footer config are all in place per the updated README. Positive signal: render tests now cover these components, and CI reliability was fixed (all test jobs run to completion, Windows PHP 8.5 and the Prettier step addressed).