Baum Laravel Package

Product Decisions This Supports

• Build vs. buy for tree data. If the roadmap includes hierarchies — category trees, org/territory structures, menu builders, threaded comments, nested taxonomies, or nested permission groups — this package answers the "do we build our own nested-set implementation?" question with "no." It supplies the model layer, tree traversal, and node movement logic so the team spends its time on product behavior instead of index maintenance.
• Data model selection. Choosing the nested-set pattern is a product-relevant decision, not just a technical one: it makes ancestor/descendant/breadcrumb reads essentially free (one indexed query) and makes reordering/moving subtrees comparatively expensive. That trade-off suits read-heavy, relatively static trees (navigation, category pages) and is a poor fit for high-write or frequently reordered structures.
• Roadmap sequencing for a major-version upgrade. v2.0.0 is a breaking release. It changes the root namespace to include the TTBooking vendor name, removes the Baum artisan command, and stops raising events during rebuilds. Any team already on 1.4.x must budget a migration sprint; any team starting fresh should adopt v2.0.0 directly rather than build against the old namespace.
• Dependency risk / abandonment decision. Adopting a community-maintained fork of an abandoned package is a conscious bet on the maintainer. The v2.0.0 release — code modernization, added static analysis, and a Testbench-based test suite — is evidence the maintainer is investing, which lowers (but does not eliminate) the succession risk. Worth tracking as a standing dependency-health item rather than a one-time approval.
• Event-driven feature design. The change to suppress events during rebuilds affects any product feature built on those events (search indexing, cache invalidation, audit logs, webhooks). This must be assessed against existing integrations before upgrade, and it is a reason to avoid architecting product behavior around rebuild-time side effects in the first place.

When to Consider This Package

Adopt when:

• You need fast ancestor/descendant/subtree reads (breadcrumbs, "all products in this category and its children") against a tree of modest size — hundreds to low tens of thousands of nodes.
• Tree structure changes are infrequent relative to reads (content taxonomy, navigation, org structure maintained by admins).
• You are on a Laravel version this fork targets, and you're comfortable pinning to a small-maintainer package with a documented upgrade path.
• You are greenfield: start on v2.0.0 so you never touch the pre-2.0 namespace.

Look elsewhere when:

• Writes and reordering dominate (collaborative sorting UIs, drag-and-drop with many concurrent editors) — nested sets rewrite index ranges on every move, and locking/contention becomes a product-visible problem.
• You need true concurrency safety on structural edits; validate the package's locking behavior against your expected edit volume before committing.
• You only need one or two levels of hierarchy — a simple parent_id adjacency column with a recursive CTE is less machinery and less dependency risk.
• You're on a database with native hierarchical support (e.g., Postgres ltree) and want to keep the logic in the database.
• You need a larger maintainer community, long-term support guarantees, or an SLA — compare against the most actively maintained nested-set alternative in the Laravel ecosystem before deciding.
• Migration-specific caution: if you are on 1.4.x with production data, treat v2.0.0 as a project, not a composer update. The namespace change touches every model, trait import, config reference, and any code referencing the removed Baum command (including deployment scripts and CI). Verify whether your app relies on events firing during a rebuild — that behavior is now gone.

How to Pitch It (Stakeholders)

To executives: This is a no-cost, open-source library that lets us ship hierarchical features — category trees, navigation, org structures — without building and maintaining that logic ourselves. It's a small, community-maintained dependency, so the real cost isn't licensing; it's the upgrade work when the maintainer ships a breaking release. v2.0.0 is exactly that: a breaking release requiring a deliberate migration. Recommendation is to adopt v2.0.0 for new work, and to schedule (not absorb) the upgrade for anything on 1.4.x.

To engineering: v2.0.0 is a major version with three changes that will bite: the root namespace now includes the TTBooking vendor segment (every import and reference must move), the Baum artisan command is deleted (audit scripts, CI, and runbooks), and events are no longer raised during rebuilds (any listener doing indexing, cache invalidation, or auditing will silently stop firing — verify this explicitly). On the positive side, the package now has static analysis and a modern Testbench test suite, which is a meaningful signal that it's actively maintained. Pin the exact version in composer.json, add a smoke test that builds and moves a subtree, and if we're on 1.4.x, plan the migration as its own ticket with a rollback path rather than folding it into feature work.