Nova Text Filter Laravel Package

Technical Evaluation

Architecture fit

• The package is a Laravel Nova extension, not a general Laravel package. It only has value inside an application that already runs Nova (a paid, closed-source first-party product) and has a licensed Nova installation pinned to a compatible major version.
• Scope is narrow: a single Nova filter UI (text input) that translates into a where-style constraint on a resource or lens query. This is one of the smallest possible extension surfaces in the Nova ecosystem — Nova's own Laravel\Nova\Filters\Filter base class already supports arbitrary field types via fields(), so a text filter is achievable in roughly 20–40 lines of in-repo code with no third-party dependency.
• Nova 4/5 moved to Vue 3 + Inertia and changed the asset/build conventions for custom filter components. Without a verified compatibility matrix, assume the package targets a specific Nova major and may not survive an upgrade.

Integration feasibility

• Low friction if the Nova version matches: composer require, register the filter class in filters() on the target resource or lens, and (for custom Vue components) ensure Nova's asset compilation picks up the package's dist/ bundle via Nova::script()/service-provider boot.
• Blockers to confirm before any work: Nova license availability, exact Nova major version in use, whether the package ships prebuilt assets or requires an npm run dev/nova:publish step, and whether the apply() signature matches the Nova version in use (apply(Request $request, $query, $value) in Nova 4+).
• Because stars and dependents are both zero, there is no external evidence of it working in production anywhere. Treat it as unvetted source code rather than as a supported dependency.

Technical risk

• Abandonment risk: high. Zero stars, zero dependents, single maintainer, and a vendor namespace (yaoko) that reads as a personal/agency namespace. No implied support path, no issue-triage history, no downstream bug surface to learn from.
• Supply-chain risk: moderate. Adding an unvetted package to a Nova app means executing third-party PHP in a privileged admin context plus shipping a JS bundle into the authenticated admin SPA. Review the service provider, the Vue component, and any published assets before use.
• Upgrade risk: high. Nova upgrades are the dominant breaking-change vector for these packages; a stale filter component will break the Nova build, not just the filter.
• Opportunity score of 23.7 and composite score of 0 corroborate the qualitative read: this is a low-leverage dependency whose entire functional value is reproducible in-house.

Key questions

1. Which Nova major version(s) does the package declare in composer.json, and does that match our installed Nova?
2. Does it ship a compiled Vue component, and is that component compatible with Nova's current asset pipeline (Vue 3 / Inertia for Nova 4+)?
3. Does the filter support lenses explicitly, or only top-level resource index queries?
4. Is the code a fork of an upstream package (the f-wangbaoshi repo owner vs. yaoko vendor suggests a possible fork lineage)? If so, what is the true upstream and its maintenance status?
5. What is the license, and is there any CLA/attribution constraint that blocks vendoring?
6. Is the text matching behavior specified — exact, LIKE %term%, case sensitivity, multi-column target? Undefined semantics here produce surprising admin UX.

Integration Approach

Stack fit

• Requirements: Laravel + Nova (licensed), PHP version aligned with both. The package is irrelevant to any non-Nova surface, so it does not enter the general application dependency graph.
• If we are not on Nova, close the evaluation immediately — there is no adaptation path.

Migration path

• Recommended: reimplement in-house. Build a TextFilter extends Filter with a single Text field, an apply() that constrains the relevant column(s), and a key()/name(). This is a small, testable, fully-owned artifact that inherits our Nova version pin and our code review. Cost is measured in hours, not sprints, and it eliminates the entire dependency-risk column above.
• Conditional: adopt with a fork. If the package's component already encodes UI behavior we want (e.g., debounce, multi-column matching, lens wiring), fork it into our own namespace, pin the Nova version, add a test, and treat it as first-party code. Do not consume the upstream repo as a live dependency.
• Do not take a plain composer require on a zero-dependent package into a production admin panel.

Compatibility

• Verify against our exact Nova major before writing code; the filter API and asset conventions differ materially across Nova 3 → 4 → 5.
• Confirm PHP constraint overlap with our runtime and check for a composer.lock conflict with Nova's own dependency tree.
• For a fork: lock the Vue/build toolchain to Nova's shipped versions rather than pulling a fresh toolchain, to avoid asset-pipeline drift.

Sequencing

1. Confirm Nova license and pinned major version (gate — stop if unmet).
2. Read the package source: service provider, filter class, Vue component, composer.json constraints, license.
3. Decide build-vs-fork (default: build).
4. Implement/prototype the filter against a single low-risk resource.
5. Validate query semantics and lens behavior with the actual admin users who requested it.
6. Roll out to remaining resources/lenses; add a regression test on apply().
7. If forked, record provenance and an owner in the internal package registry.

Operational Impact

Maintenance

• Adopting the package as-is transfers all maintenance to us with none of the ownership: we inherit the code but the upstream will not track Nova releases. Every Nova upgrade becomes a manual compatibility audit of a dependency no one on the team wrote.
• A forked or in-house filter has the same maintenance cost but with full context, review history, and the ability to fix issues directly.

Support

• No vendor support, no SLA, no known production users to consult. Internal escalation path is "read the source," which for a small component is acceptable — but that argues again for ownership rather than consumption.
• Nova itself is closed-source and support-backed; keeping our extension surface small and first-party keeps the Nova support relationship clean.

Scaling

• Runtime cost is negligible: the filter only affects admin index queries, which are low-QPS relative to the application. The real scaling concern is query shape — an unanchored LIKE %term% on a large table will do a full scan and can degrade the admin index for high-row-count resources. Specify the matching strategy and, where needed, constrain to indexed columns or require a minimum term length.
• Admin concurrency, not data volume, is the practical ceiling; Nova index performance is the limit, not this component.

Failure modes

• Silent no-op filter: apply() signature mismatch with the Nova version — filter renders, returns unfiltered results, and no one notices until an admin acts on the wrong dataset. Mitigate with a test asserting the generated SQL/bindings.
• Broken admin build: Nova asset compilation fails after a Nova or Node upgrade, taking down the whole admin panel — not just the filter. This is the highest-blast-radius failure and the strongest argument for forking.
• Injection/escaping defects in the JS component or unparameterized query construction in apply().
• Abandonware drift: no upstream fixes; the package silently becomes incompatible and the failure surfaces during an unrelated upgrade window.
• Fork ambiguity: if f-wangbaoshi/nova-text-filter is itself a fork, license and provenance obligations may be unclear.

Ramp-up

• Low technical ramp-up: any Laravel developer can read and reproduce this component in under a day. That low barrier is itself the finding — the package's value proposition is weak relative to the cost of taking on an unmaintained dependency.
• The real ramp-up cost is process: establishing provenance review, an internal fork policy, and Nova-upgrade regression testing for admin extensions. Worth doing once, independent of this package.
• Recommendation: decline adoption as a live dependency. Reimplement the text filter in-house (or vendor a reviewed fork) as a small first-party Nova extension, and spend the saved risk budget on a Nova-upgrade regression checklist. The opportunity score of 23.7 is consistent with this: the capability is useful, the package is not the vehicle.