Wirelist Laravel Package

Product Decisions This Supports

• Build vs. buy for commodity UI. Every admin panel eventually rebuilds the same table: paginate, search, sort, show columns, wire up row actions. Wirelist is a candidate answer to "do we build this a fourth time?" — the answer should default to borrow unless the screen is a differentiator.
• Backlog acceleration on internal tooling. Back-office epics (user management, order/support queues, content moderation, tenant admin) are usually value-neutral infrastructure work that customers never see. A package that collapses "list screen" from a 1–2 day build to hours shortens those epics without touching product differentiation.
• Scoping the internal admin standard. This is an input to a bigger decision: do we standardize an admin kit (list component + form component + authz conventions), or keep assembling per-feature? Wirelist answers only the list slice; the decision is whether the slice is worth standardizing on a 1-star, single-maintainer dependency.
• Roadmap sequencing. If list screens are cheap, roadmap capacity shifts from "admin refresh" to customer-facing work. That reallocation is the actual product value here, not the component itself.
• Feature-level use cases it fits: CRUD index pages, approval/work queues, dashboards, tenant or account management, any Eloquent-backed collection with inline edit/delete.
• Decisions it does not support: customer-facing surfaces, anywhere the design system, accessibility conformance, or brand consistency is a differentiator, and anywhere we need a vendor SLA or roadmap commitment. Those stay in-house or move to a maintained alternative.

When to Consider This Package

Adopt-consider criteria (all should hold):

• The application is already Laravel + Livewire, and the package's declared constraints on PHP, laravel/framework, and livewire/livewire include our locked versions. Verify with composer why-not — a failed constraint is a hard stop, not a workaround.
• The screen is commodity list UX — pagination, search, sorting, columns, row actions — with no bespoke interaction or bespoke visual language.
• The audience is internal. A slightly generic table is fine; a slightly generic table on a marketing or checkout surface is not.
• We wrap it. A thin adapter (subclass or Blade partial) means a future swap is a single-file change. This is the highest-value risk mitigation available and should be a precondition, not a nice-to-have.
• Someone owns the upgrade ritual: ~30–60 minutes per release reading the diff, because 1.1.0 shipped with an auto-generated changelog link and nothing else. Budget it as a permanent line item.
• MIT licensing fits our distribution model and we can vendor/fork if the maintainer goes dark.
• Actions are gated with policies — the component does not enforce authorization by default, so edit/delete must be gated in our subclass or via Gate::allows.

Look elsewhere when:

• We are on, or about to move to, a Livewire major the package does not declare support for. Do not adopt on a version boundary.
• The surface is customer-facing, accessibility-critical, or governed by a design system — the value is in consistency, and a third-party table undermines it.
• We need support commitments, a security contact, or predictable release notes. One maintainer, one star, and an empty minor-release changelog is a "we own it" dependency, not a vendor relationship.
• Expected list cardinality is large and unproven. Livewire payload size and per-row query behavior (N+1) are the usual cliffs; load-test at 2–3× expected volume before putting it on a high-traffic screen.
• There is a maintained alternative already in the stack (an admin framework or table component) — adding a second table idiom costs more in consistency than it saves in boilerplate.

How to Pitch It (Stakeholders)

For executives (one paragraph): Wirelist is a free, MIT-licensed Laravel add-on that removes repetitive code from internal list and table screens — search, sorting, pagination, columns, row actions. It costs nothing to try and, if we wrap it in our own thin adapter, costs little to remove. The risk is not money or lock-in, it is dependency hygiene: it is a single-maintainer package with a very small user base and a release history that does not document its own changes. Recommendation: approve a time-boxed 1–2 day spike on one non-critical admin screen behind a feature flag. Do not standardize on it yet, and set the expectation up front that we may need to fork it or replace it. The decision requested today is permission to evaluate, not adoption.

For engineering leadership (summary): It is a presentation-layer Livewire component — you hand it an Eloquent query or collection and it renders a paginated, sortable, searchable list with configurable columns, customizable via columns(), actions(), and render() overrides, with no frontend build step. Integration is a Composer require plus optional config/view publishing. Three things gate the spike: confirm the composer.json constraints cover our PHP/Laravel/Livewire versions; read the 1.0.1...1.1.0 diff before installing, because the release note is only a compare link and we cannot classify the change from the note alone; and confirm nothing global is registered — routes, view namespaces, or config keys that could collide.

Plan and ask:

1. Spike on one non-critical screen with real data shape and real pagination needs (1–2 days).
2. Pin the exact version, wrap behind an adapter, ship behind a flag.
3. Gate all edit/delete actions with policies — authorize explicitly, assume nothing.
4. Add to the dependency register with an owner, pin rationale, and last-reviewed date; configure automated dependency PRs to require manual approval for this package specifically.
5. Decide on a caret constraint only after the next release proves the upgrade path.

What success looks like: one list screen delivered in a fraction of the usual effort, a single-file removal path, and no surprises at the next Laravel or Livewire upgrade. What failure looks like: the component gets copy-pasted across a dozen screens with no adapter, the maintainer stops shipping, and a Livewire major bump turns a routine platform upgrade into a fork.