Baum Laravel Package

Product Decisions This Supports

Feature decisions

• Hierarchical content and navigation. Category trees, mega-menus, site navigation, documentation sidebars, org/department structures, permission or taxonomy trees, threaded discussions, and location hierarchies are all natural fits for a nested set. If a roadmap item is "let admins drag-and-drop reorder our category menu" or "show breadcrumbs on every product page," this package is the enabling primitive.
• Breadcrumbs, ancestors, and subtree pages in one query. Any feature that renders a node's full ancestry chain (breadcrumb, URL path, permission inheritance) or a full subtree ("everything under Appliances") becomes a single indexed WHERE lft BETWEEN ? AND ? instead of N+1 recursion. That is a user-visible latency decision, not just a code-style one.
• Depth-limited experiences. limitDepth() and depth columns support "show top 2 levels only" navigation, progressive category expansion, and sitemap generation without loading the whole tree.
• Multi-tree / multi-tenant trees. The scoped property plus inSameScope() means one table can hold many independent trees (per tenant, per site, per storefront), which can avoid a separate table-per-tenant migration.
• Ordered reordering UX. moveLeft, moveRight, moveToLeftOf, makeFirstChildOf, makeSiblingOf map directly to drag-and-drop admin interactions and to "pin this item above that one" product requests.

Build vs. buy

• Buy (adopt) when the tree is read-heavy and shallow in business complexity. The package has ~93% test coverage, a real CI pipeline, an artisan generator, and configurable column names — that is meaningfully cheaper than hand-rolling and debugging boundary recalculation.
• Build when you need closure tables, DAGs (a node with multiple parents), per-node audit history, or cross-tree graph queries. Nested set is a strictly-tree model; forcing it onto a graph is a rework you will pay for twice.

Roadmap / platform implications

• Nested set shifts cost from read to write. Reordering or inserting a node rewrites lft/rgt across a large slice of the table. This is a capacity planning input: if the roadmap includes bulk imports, frequent admin reshuffles, or a high-write category feed, budget for transactions and row locks, or isolate the tree in its own table so writes don't contend with the main entity table.
• Keep tree data lean (a name plus one or two attributes, per the README's own guidance). Treat "we want to add more columns to the tree table" as a signal to revisit the pattern, not to keep stacking columns.

When to Consider This Package

Adopt when most of these are true

• Reads dominate writes: the tree is queried on nearly every page view but modified rarely (catalog taxonomy, CMS navigation, static org chart).
• You need whole-subtree or full-ancestry retrieval in a single query, at arbitrary depth.
• Tree nodes carry little more than a label and one or two descriptive attributes.
• Ordering matters and users expect to reorder siblings.
• You're on Laravel 5.8–13 and want Eloquent-native behavior (relations, query scopes, moving/moved model events, soft deletes, mass-assignment guards) rather than raw SQL.
• You want a php artisan make:baum scaffold and configurable parent_id/lft/rgt/depth column names to fit existing schema conventions.
• You want a per-tenant or per-site scoping story without extra tables.

Look elsewhere when any of these are true

• Write-heavy trees. Frequent inserts, deletes, or moves rewrite large ranges of lft/rgt under lock. Adjacency list with recursive CTEs (Postgres/MySQL 8+), ltree, or a closure table will serve you better.
• Rich relational data on nodes. If nodes accumulate many related entities, statuses, pricing rules, or translations, the README's own caveat applies — nested set becomes a poor fit.
• Graphs, not trees. Multiple parents, cross-links, or "related items" as first-class edges.
• Strict deletion semantics. Descendant deleting/deleted events are not fired; if downstream systems (search index, webhooks, cache invalidation) depend on per-node events, you must build that yourself.
• High-concurrency reordering. Nested set has well-known race conditions on simultaneous writes; you'll need explicit transactions, locking, or a single-writer queue.
• Ecosystem and support risk tolerance is low. With 32 stars and 0 dependents, this is a small-footprint fork of a historically dormant package. There is no commercial support, no large community to lean on, and a bus factor of roughly one. If your org requires vendor SLAs, third-party security review, or a broad hiring pool familiar with the library, this will not clear procurement. Budget for the possibility of forking it internally — the MIT license and 93% coverage make that a realistic fallback rather than a disaster.

Mitigation if you adopt: pin the version, wrap all tree mutations behind a thin internal service/repository (so the package is swappable), add your own integration tests around move/reorder/delete paths, and keep lft/rgt columns indexed.

How to Pitch It (Stakeholders)

For executives (30 seconds): We have several roadmap features that are all the same underlying problem — categories, navigation menus, and permission hierarchy are all trees. Rendering them the naive way means recursive database queries that get slower as the tree grows. This package is a free, MIT-licensed Laravel component that stores the tree so any subtree or breadcrumb is a single indexed query, regardless of depth. It's a small, low-risk dependency that avoids building and maintaining that logic ourselves, and it directly enables the drag-and-drop category management and fast navigation work already on the roadmap.

For engineering (the honest version):

• What it is: a maintained fork of the established Baum nested-set implementation for Eloquent, with Laravel 5.8–13 support, ~93% test coverage, CI, an artisan model/migration generator, configurable column names, tenant scoping, soft deletes, and moving/moved hooks. The API will look familiar to anyone who has used Baum before.
• The trade: reads become trivially fast; writes become more expensive because moves and inserts rewrite boundary values. That's an acceptable trade for navigation and taxonomy data and an unacceptable one for write-heavy trees. We should decide per-domain, not adopt it as a blanket policy.
• Known gaps to own: descendant delete events don't fire; concurrency on concurrent moves needs transactions/locking; the package is a low-star fork with no commercial backing, so we pin versions and keep all mutations behind an internal service so we can swap it out.
• Recommended scope: adopt for read-heavy, attribute-light ordered trees (catalog taxonomy, navigation, org structure). Do not adopt for graphs, closure-table needs, or high-write trees — those get a different pattern.