Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Nested Tree Filter Laravel Package

gekich/nested-tree-filter

A Laravel package for filtering nested tree structures, making it easier to query hierarchical data like categories and menus while preserving parent-child relationships in filtered results.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Feature scoping for admin/internal tooling: If your roadmap includes hierarchical data management in Laravel Nova (categories, org units, taxonomies, folder-like structures), this package is a ready-made reference for a nested tree filter UI. It can help validate whether “filter by branch/descendant” is a real user need before committing engineering time.
  • Build vs. buy (or build vs. fork): With an MIT license and a small, focused codebase, the package supports a “fork and own” decision rather than a long-term dependency decision. A PM can use it to estimate the effort of building a Nova filter in-house: the package demonstrates the shape of the component, the filter contract, and the tree-selection UX.
  • Roadmap de-risking: Because it is archived and has near-zero adoption (6 stars, 0 dependents, last release 2021), it is best treated as a prototype/reference implementation, not a strategic dependency. That supports a roadmap decision to prototype an internal Nova filter quickly, then decide whether to harden it or replace it.
  • Use cases to validate: Back-office admin screens where support/ops teams need to narrow records by a node and its descendants—e.g., “show all tickets in the EMEA > UK > London branch.” The package is relevant when the primary value is faster internal workflows, not customer-facing differentiation.
  • Maintenance-cost modeling: An archived package forces an explicit ownership decision. A PM can use it to ask: do we have a PHP/Laravel engineer who can own a forked Nova filter, or should we avoid this capability until we do?

When to Consider This Package

Consider it when:

  • You are already on Laravel Nova and need a nested/hierarchical filter for an internal admin panel.
  • The requirement is narrow: select a tree node and filter resources by that node and/or its descendants.
  • You are comfortable vendoring, forking, or copying the implementation under MIT rather than depending on upstream maintenance.
  • You have engineering capacity to own the code, review Nova compatibility, and add tests.
  • You want to prototype a tree-filter UX cheaply before investing in a custom build.

Look elsewhere when:

  • You need a maintained, supported dependency with security updates and Nova version compatibility guarantees—this package is archived and last released in 2021.
  • You are not using Laravel Nova, or you need framework-agnostic tree filtering.
  • You need advanced behavior: search within the tree, async loading for large hierarchies, multi-select with parent/child semantics, permission-aware trees, or auditability.
  • Your organization requires vendor support, SLAs, or a clear upgrade path.
  • The hierarchy is large or frequently changing and needs performance work beyond a simple filter component.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Laravel Nova filter that can accelerate an internal admin capability—filtering records by nested categories or org structures. It is not a strategic vendor dependency: the project is archived, has minimal adoption, and was last released in 2021. The recommended play is to treat it as a reference implementation or a forkable starting point, not a supported product. That keeps cost low and avoids lock-in, but it requires internal engineering ownership.

For engineering: The package is a focused Nova filter for nested tree selection. It is useful as a pattern/reference for the Nova filter API and tree UI, but because it is archived with zero dependents, we should not add it as an unowned Composer dependency. If we pursue the capability, plan to fork/vendor it, pin Nova compatibility, add tests, and assign an owner. If the requirement is more than a simple descendant filter, budget for a custom build instead.

For product: Use this to validate the need for hierarchical filtering in admin workflows. If the use case is real and narrow, a fork can deliver a quick win. If the use case expands—search, permissions, large trees, multi-tenant hierarchies—treat the package as a prototype and plan a proper internal component.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
coleus/frame
thtg88/journalism
filagora/filagora-ai-forums
rlacerda83/query-parser
socialdept/atp-orm
cboxdk/laravel-assistant-client
socialdept/atp-resolver
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings