Poke Laravel Package

Product Decisions This Supports

• Inline validation UX for identifiers. The package's core value is answering "does this record exist?" cheaply, without hydrating a model — the exact question behind username, slug, SKU, invite-code, coupon, and tenant-key fields. This release makes that answer available directly inside Livewire components and Filament forms, so "validate as the user types" becomes a config decision rather than a custom-build decision.
• Build vs. buy on form validation glue. Teams routinely hand-roll Rule::exists(...) wrappers, debounce logic, and per-model lookup helpers. That is undifferentiated code with a long tail of edge cases (soft deletes, scoped queries, case sensitivity). A maintained package with first-party UI integrations is a straightforward buy, priced at roughly one dependency.
• Admin panel roadmap. Shipping Filament helpers is a direct signal that the maintainer intends this to be used inside Filament resources — the fastest path most teams have to internal tooling. If Filament is on your roadmap, this removes a small but recurring piece of custom work per resource.
• Stack standardization. First-party Livewire + Filament support is a bet on the TALL stack. If you are choosing an admin/UI stack this quarter, this is a minor but real point in favor of TALL over alternatives where the package would be inert.
• Risk posture on dependency count. Adoption here is a low-blast-radius decision: the package sits on a read path (validation), not on auth or persistence, so a bad release degrades a form, not data integrity. That makes it a reasonable "just take the dependency" call rather than a platform-level evaluation.

When to Consider This Package

Consider adopting when:

• You are on Laravel with Livewire and/or Filament already in the stack — v5.1.0's helpers are the reason to look now, and they are worthless if you are on a Blade/Inertia-only front end.
• You have several models needing existence/uniqueness feedback in forms, where the duplication cost of hand-rolled rules is real.
• You want consistent behavior across resources (soft-delete handling, scoping, case rules) enforced in one place rather than per feature.
• You are pinning to the 5.x line and want additive upgrades; v5.0.0 → v5.1.0 is a feature addition with no breaking changes, so the upgrade cost is a composer update and a smoke test.

Look elsewhere or skip when:

• You need one check in one form. Laravel's built-in exists/unique validation rules cover it; a dependency is overhead.
• The check is not a simple existence lookup — availability windows, entitlement logic, rate limits, or permission-scoped visibility belong in your domain layer, not a validation helper.
• You are not on Livewire/Filament. The new release adds nothing for you; evaluate the package on its own merits and expect slower movement toward your stack.
• Per-keystroke queries are unacceptable in your environment. The integration shifts load to the read path in a way that needs debouncing, caching, and proper indexes — if you cannot invest that, submit-time validation is safer.

Adoption gate: verify the Livewire/Filament helper versions match your installed majors, and confirm the package's Laravel/PHP support matrix covers your oldest deployed app before standardizing across projects.

How to Pitch It (Stakeholders)

For executives (one paragraph): A small, low-risk Laravel dependency that improves the signup and admin-form experience — users find out immediately whether a username, code, or SKU is taken instead of after submitting. The new v5.1.0 release adds native support for Livewire and Filament, the two frameworks our internal tools and forms are built on, which means we get this behavior without custom code per screen. Cost is one dependency and a patch-level upgrade; risk is contained to form validation, with no impact on data integrity or authentication. Recommend adopting on new Filament resources and Livewire forms, and standardizing rather than re-implementing lookup rules per feature.

For engineering leads: v5.1.0 is additive — Livewire and Filament helpers over the existing existence-check primitive, no breaking changes from v5.0.0. Adopt behind a pinned ^5.1 constraint, add feature tests around any form that uses it, and treat the results as UX hints, never as authorization. Watch the read path: debounce input-triggered checks, ensure the underlying columns are indexed, and confirm soft-delete/scoping semantics match each model's expectations before rolling out broadly. If we already maintain bespoke existence rules in more than two places, this is a net code reduction — start there as the pilot.