Nested Tree Filter Laravel Package

Technical Evaluation

Architecture fit. Laravel Nova custom filters are a first-class, sanctioned extension point: a Filter subclass registered via filters() on the resource, paired with a Vue component compiled into Nova's asset bundle. Blast radius is confined to the Nova admin surface — no coupling to the customer-facing application, no database schema changes, no queue or event surface. That is the most favorable possible shape for adopting a small third-party package.

The caveat is that Nova filters reach into Nova's internal frontend contracts (laravel-nova mixins, internal component APIs, the asset pipeline), which are explicitly not covered by semver stability guarantees. This package's value proposition — filtering a resource by an ancestor node in a hierarchy — also has two very different implementation shapes: (a) client-side tree rendering that submits a resolved ID set to a whereIn, or (b) server-side recursive descendant resolution. Shape (a) is simple and degrades with tree size and request-size limits; shape (b) requires a sane tree storage model (closure table, materialized path, or recursive CTE). We do not know which shape this is without reading the source, and that single fact drives the entire scaling risk.

Integration feasibility. Low-to-moderate technically, but gated almost entirely by Nova major version. The last release (2021-11-18) lines up with the Nova 3.x era (Vue 2, Laravel 8, Laravel Mix). Nova 4 moved to Vue 3 and a Vite-based asset toolchain; Nova 5 tracks Laravel 11/12. On any modern Nova install, this is realistically a port, not an install. Because it is MIT, the credible path is fork-and-vendor into first-party code rather than composer require.

Technical risk. High, and concentrated in abandonment rather than code quality:

• Archived upstream. No compatibility fixes, no security response, no issues triage. Whatever we adopt, we own permanently.
• Zero field validation. 6 stars and 0 dependents means no production usage signal anywhere. We would be the first serious consumer.
• Version drift is near-certain. PHP, Laravel, and Nova constraints in composer.json will almost certainly exclude our stack; the Vue component will almost certainly not compile against a post-3.x Nova toolchain.
• Reviewability. Check whether compiled JS is committed. Unreviewable dist bundles in an admin surface that can read all tenant data are a supply-chain concern, even at this star count.

Key questions for the spike.

1. What Nova major and Laravel/PHP versions are we actually pinned to, and does the package's composer.json admit them?
2. How is the tree stored — adjacency list, nested set, closure table, or recursive CTE — and which resolution shape (a) or (b) above does the filter use?
3. Does the filter enforce model policies and existing tenant/global scopes, or can it widen visibility rather than narrow it?
4. Are frontend assets prebuilt, or is source present and buildable against our Nova toolchain?
5. What is our real tree depth and node count, and what is the upper bound on the ID list the filter submits?
6. What would a first-party reimplementation cost? (A basic descendant-ID filter with a Vue tree is realistically 0.5–2 dev-days; a hardened one with caching and authorization tests is 3–5.)

Integration Approach

Stack fit. Only relevant if we already license Nova and run Laravel. Nova is a paid first-party product, so there is no licensing friction, but there is also no portability: none of this work transfers to Filament or Backpack without a rewrite. If Nova is a legacy surface we intend to retire, this package is a distraction.

Migration path. There is no data migration — filters are stateless UI over existing queries. The migration is organizational: convert an archived dependency into owned source. Concretely, copy the filter class into app/Nova/Filters/ and the Vue component into our Nova asset source directory, retain the MIT header, and delete the Composer dependency entirely. Do not attempt to run this as a live upstream package; archived plus version drift means we would be patching in vendor/ within a sprint.

Compatibility. Treat Nova-version compatibility as the go/no-go gate. The asset toolchain changed between Nova majors (Mix in 3.x, Vite-based in 4.x+), and the Vue major changed with it, so a component written for one major will not compile for the other without edits. Verification steps: confirm the component's Vue API surface against our Vue major; confirm our Nova asset build picks up the new component; confirm the Filter base class signatures still match (notably apply(), options(), and any key/component conventions).

Sequencing.

1. Timeboxed spike (1 day): read the source, answer the six questions above, decide port vs. rewrite.
2. Decide the query strategy first — descendant-ID resolver with caching — because that determines whether the UI work matters.
3. Port or rewrite the Vue component against our Nova major; wire it into the build.
4. Add authorization and tenant-scoping tests asserting the filter can only narrow result sets, never widen them.
5. Ship behind a feature flag to one admin team; measure index-page latency before and after.
6. Retain first-party ownership, with the upstream repo referenced only as provenance in a code comment.

Operational Impact

Maintenance. Total cost of ownership shifts entirely in-house. Archived upstream means every Nova major upgrade (roughly annual) carries a known, budgetable task: re-verify the filter against the new Vue major and asset pipeline. Allocate a standing line item of ~2–5 dev-days per Nova upgrade. There is no CVE response process, so treat the package as code we wrote, not code we consume.

Support. None. No upstream triage, no maintainer contact, no community mass — six stars means no Stack Overflow corpus and no blog posts. Internal documentation is mandatory, not optional: a short README covering the tree model assumption, the cache key scheme, and the upgrade checklist.

Scaling. Entirely a function of tree shape. Risks in order of likelihood:

• Deep-tree descendant resolution on every Nova index load, adding recursive queries to a page that already paginates a resource.
• Unbounded whereIn ID lists hitting request-size or query-plan limits on broad selections.
• N+1 queries rendering the tree itself if node labels load lazily per row.
• Stale descendant caches after nodes are moved or re-parented.

Mitigations: resolve descendant sets server-side, cache per node with explicit invalidation on tree mutation, cap selectable nodes, and add an index-page latency budget to CI or at minimum to release checks.

Failure modes. The dangerous ones are silent:

• Fails open. The filter renders but does not constrain the query — an admin reads a filtered list as if it were scoped. This is the highest-severity mode for a filter over tenant data; assert filtering in tests, don't eyeball it.
• Deploy-breaking asset failure. A component that stops compiling against a new Nova toolchain breaks the admin build, not just the filter. Stage Nova upgrades with the admin bundle in scope.
• Permission leakage. A filter that composes queries without the model's global scopes can widen visibility. Filters must intersect with existing authorization, never replace it.
• Silent removal on upgrade. Nova major upgrades can drop unregistered or incompatible filters without a loud error; the feature simply disappears.

Ramp-up. The codebase is small; a mid-level Laravel developer absorbs it in one to two days. The real learning curve is Nova's undocumented filter internals, which concentrates knowledge in whoever does the port — bus factor of one unless we pair deliberately. Budget for a second engineer to shadow the port and co-own the upgrade checklist.

Bottom line. Not adoptable as a dependency; potentially adoptable as source. Fund a one-day spike, expect to rewrite rather than port, and only proceed if the first-party reimplementation estimate (0.5–5 dev-days) exceeds the fork-and-harden estimate — which, given zero field validation and an archived upstream, it probably does not.