Filament Resource Picker Laravel Package

Technical Evaluation

Architecture fit

• Filament packages are conventional Laravel packages: a service provider, a Livewire-backed form component, and Blade views. A resource picker is an additive UI control — it should not require schema changes or touch domain/application layers, which keeps blast radius small.
• Fits naturally into the admin-panel tier of a Laravel app. It is not appropriate for anything customer-facing or outside a Filament panel, so treat it as a back-office convenience, not platform infrastructure.
• Scope is narrow and single-purpose, which is generally favorable: easy to reason about, easy to replace.

Integration feasibility

• Expected path: composer require wotz/filament-resource-picker, then register the plugin/component on the target panel and reference the field in a Filament form schema. Standard, low-ceremony.
• The real feasibility question is version alignment: Filament 3.x vs 4.x changed the Forms/Schema APIs materially, and Livewire 3 constraints must match the host app. Validate with composer why-not before committing.
• A half-day spike against the pinned Filament version is sufficient to prove or kill the integration.

Technical risk

• Adoption risk (high): 2 stars, 0 dependents, single maintainer → bus factor of 1. The composite score (9.3) reflects functional promise; the opportunity score (21.2) and near-zero ecosystem signal reflect maturity, not quality. Do not conflate them.
• Release metadata anomaly: the stated last release (2026-04-16) is future-dated relative to normal consumption; verify this is a real stable tag and not a pre-release or metadata artifact before relying on it.
• Upgrade risk (medium-high): Filament ships majors frequently; without an explicit support matrix and CI matrix, expect breakage on the next major bump.
• Abandonment risk (medium): fully mitigated by MIT + small surface area — vendoring or reimplementing is cheap.
• No evidence of test suite/CI in the supplied metadata; absence of dependents means no third-party battle-testing.

Key questions

1. Which Filament major versions are supported, and is there a published support matrix?
2. Does it handle morph/polymorphic relations across multiple resource types, or a single resource only?
3. How are authorization (policies) and multi-tenancy applied to the option list? Do global scopes and canViewAny gate results?
4. What is the search strategy for large tables — debounce, minimum query length, result caps, eager loading?
5. Is the option label customizable (resource title attribute, getOptionLabel, closures)?
6. What is the public extension surface, and how stable is it across releases?
7. Is there a test suite and CI pipeline, and what are the exact PHP/Laravel/Livewire constraints?
8. Is the 2026-04-16 tag a stable release?

Integration Approach

Stack fit

• Assumes Laravel 10/11/12, PHP 8.1+, Livewire 3, Filament 3.x or 4.x. Confirm the constraint set resolves cleanly against the host composer.lock before any code is written.
• Best fit is an internal admin panel with modest editor concurrency and mid-sized reference tables.

Migration path

• Treat the package as a swappable UI adapter: keep form schema definitions in application code, reference the field there, and avoid letting package-specific classes leak into domain or service layers.
• No data migration is expected — a picker is presentational. If it is being introduced to replace a free-text ID field or a raw Select, that is a data-quality improvement, not a schema change.
• Wrap in a feature flag so the field can be reverted to a native Select per-panel without a deploy rollback.

Compatibility

• Pin to an exact version with a tight constraint; avoid floating ranges on a single-maintainer package.
• Add a CI matrix job that resolves lowest and highest supported dependency sets — this is the cheapest early warning for Filament-upgrade breakage.
• Verify the package does not pin conflicting Livewire or Filament constraints that would block your own upgrade cadence. If it does, that is a disqualifier.

Sequencing

1. Spike (0.5–1 day): install in a throwaway panel on the target Filament version; exercise morph, tenancy, and large-table search.
2. Due diligence: close out the key questions; inspect commit history and issue responsiveness.
3. Pilot: one non-critical admin surface behind a flag.
4. Design review: decide adopt vs. fork/vendor vs. build in-house. If the required behavior is a standard Filament Select with relationship search plus a resource lookup map, in-house is likely under a day of work — weigh that against dependency ownership.
5. Expand: only after surviving one Filament upgrade cycle without an upstream patch.

Decision gate: adopt if maintenance is active and the API is stable; vendor/fork if the behavior is valuable but upstream stalls; build in-house if the implementation is thin and authorization semantics need to be tightly controlled.

Operational Impact

Maintenance

• Assume you own the upgrade path regardless of upstream health. Schedule a quarterly dependency review and an explicit check on each Filament major.
• Maintain a fork-ready posture: MIT license plus a small code surface makes vendoring a one-day exercise. Keep the fork procedure documented.
• Budget roughly 1–2 engineer-days per quarter for upkeep and version bumps.

Support

• Community-only; no SLA, no commercial backing. Escalation path is reading the source and patching locally.
• Assign a named internal owner and record the pinned version and rationale in the dependency register. Undocumented single-maintainer dependencies become tribal knowledge and then incidents.

Scaling

• The primary scaling concern is query volume, not throughput: per-keystroke search over large tables can generate expensive LIKE scans. Enforce a minimum search length, debounce, and a result cap.
• Cross-resource pickers multiply requests per form render — cache static option lists and avoid loading pickers in collapsed/hidden schema sections.
• Admin-panel concurrency is low (tens to low hundreds of editors); Livewire round-trips are acceptable at that scale.

Failure modes

Ramp-up

• A Filament-familiar engineer reaches productivity in roughly half a day; the API mirrors native form components.
• Documentation is likely thin for a package of this age — plan for source-reading and write internal usage notes at pilot time.
• Low onboarding burden overall, but the small ecosystem means internal documentation is the substitute for community answers; do not skip it.