Getting Started

Do not install this package for new work. The 0.1 release notes explicitly say “Don’t use it” and describe it as based on an older version of etrepat/baum.
If you are evaluating it anyway, start by inspecting:
- composer.json for Laravel/PHP version constraints
- the service provider and migration stubs
- the model trait/interface used for nested-set behaviour
The first realistic use case would be hierarchical data such as categories, menus, or threaded comments. For those, prefer a maintained nested-set package such as kalnoy/nestedset unless you have a specific reason to stay on a Baum-derived implementation.
Treat 0.1 as a proof-of-concept or legacy compatibility shim, not a production dependency.

Implementation Patterns

If you must use it, isolate it behind your own repository/service layer so the package can be replaced without touching domain code.
Pin the exact version in composer.json and commit the lock file. Do not rely on floating constraints.
Exercise tree-moving operations heavily in tests: moveTo, sibling reordering, deletion, and subtree moves. The release notes call out reordering issues in newer Baum versions, so assume move operations are the highest-risk area.
Wrap structural changes in database transactions where possible, and avoid concurrent writes to the same tree.
Prefer rebuilding or re-seeding the tree over complex in-place reordering if you hit inconsistent left/right bounds.
For integration, verify how the package registers migrations and whether it expects specific column names (lft, rgt, parent_id, depth) before writing application code around it.

Maintenance risk is the main gotcha. “First and maybe last” signals likely abandonment; bug reports and Laravel compatibility fixes may never arrive.
It is based on an older Baum version, so it may inherit outdated Laravel APIs and may not work cleanly with modern Laravel releases.
Newer Baum versions reportedly have reordering issues; this package deliberately tracks an older baseline, so you get old behaviour rather than maintained fixes.
Debugging nested-set corruption:
- inspect lft/rgt values before and after each move
- assert tree integrity after every structural operation
- log the SQL generated by move operations
Extension points are likely limited to the model trait and package config. If you need fixes, expect to fork rather than configure around them.
Because there is no prior assessment or release history, there is no evidence of a stable API. Treat every method as potentially changing or broken.
Recommendation: use a maintained alternative for new projects; only consider this package for legacy Baum-shaped schemas where migration cost is the dominant concern.