Nova Global Filter Laravel Package

Product Decisions This Supports

• Build vs. buy for admin tooling. Nova's native filter API is per-resource and requires each resource's filters() method to opt in. If your support/ops team filters the same dimension (tenant, region, plan, date window) across five or more resources, that's repeated boilerplate and repeated clicks. This package targets exactly that gap. The decision it informs is: spend 3–5 dev days building an internal global filter layer, or adopt and fork an MIT-licensed one for ~1 day of spike time.
• Multi-tenant and scoped-admin roadmap. If your roadmap includes giving support staff or account managers a scoped view of a single customer across all Nova resources, a global filter is a prerequisite capability, not a nice-to-have. This is the strongest use case and worth evaluating against.
• Internal-tool investment level. Admin panels are cost centers, not differentiators. That argues for the cheapest viable option that doesn't create upgrade debt — which makes a small, forkable, MIT package a legitimate candidate, provided you cap the exposure.
• Nova upgrade planning. Any package that hooks Nova's filter lifecycle is coupled to Nova's major version. Adopting this adds one more item to your Nova upgrade checklist; that cost belongs in the decision, not discovered later.
• Not supported: customer-facing filtering, shared/persisted filter state across users, reporting or export, or anything requiring auditability of who filtered what. Nothing in the package signals those capabilities.

When to Consider This Package

Consider it when all of the following hold:

• Laravel Nova is already in your stack and staying there for at least the next major version.
• The need is internal-only, low blast radius, and reversible.
• Your team is willing to read the source, fork it into an internal namespace, and own it — assume you are adopting code, not a supported product.
• The alternative (build it yourself) genuinely costs more than a day of engineering, which is true if you'd be writing the Vue filter component and the cross-resource registration glue from scratch.

Look elsewhere, or build in-house, when:

• Adoption signals matter to you. One star, zero dependents, and a single maintainer mean no community validation, no third-party bug reports, and a bus factor of one. You are the first real user.
• You need support SLAs, security review, or a documented API contract. MIT gives you legal permission, not assurance.
• You need this to survive a Nova major upgrade without intervention.
• Your requirement is richer than scoping — saved filter sets, per-user persistence, sharing, or reporting — where a purpose-built internal tool or a BI layer is the better investment.
• You already maintain several Nova custom tools; each additional one compounds upgrade surface area.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed component that could remove a recurring daily friction for our support team — re-applying the same filters on every admin screen. It is internal-only, invisible to customers, and cheap to reverse: one engineer-day to evaluate, and if it doesn't hold up we discard it at that cost. The realistic downside is bounded at that one day; the realistic upside is not rebuilding admin filtering ourselves.

To engineering: Treat this as a source-code acquisition, not a dependency. Spike it against our Nova version, confirm it isn't reaching into undocumented internals, and if it works, vendor a fork under our namespace so we control the upgrade path. Recommend a time-boxed evaluation with an explicit "fork or drop" decision at the end — no silent long-term dependency on a one-star package.