Navigation Module Laravel Package

Product Decisions This Supports

• Editor-managed navigation vs. hard-coded menus. This module's core value is a data model plus admin UI for menus and their links, so non-technical stakeholders can restructure primary/footer/sidebar navigation without a deploy. That is a roadmap decision, not just a build detail: it determines whether "update the nav" is a marketing self-serve task or an engineering ticket.

• Feature scope for a first CMS-backed release. Concrete capabilities to scope against: multiple named menus, nested/hierarchical link trees, drag-and-drop reordering, and link targets that can be a raw URL, a referenced page, or a route. Any of those missing shifts work back onto your backlog.

• Build vs. buy for a navigation builder. The build side is a tree table, a reorder endpoint, a link-type registry, and an admin screen — roughly a sprint for a competent Laravel team, plus permanent maintenance. This package is the buy side, conditional on already running the Streams Platform (Anomaly Labs' CMS framework, formerly PyroCMS). On plain Laravel it is not a buy; it is a framework adoption disguised as a menu feature.

• Platform evaluation. Because this is a module rather than a standalone package, trialing it is effectively a trial of the Streams Platform. Treat it as evidence in a "should we standardize on this CMS" decision.

• Multi-site / multi-locale navigation. If menus must be scoped per site, per locale, or gated by role/permission, validate those paths early — they drive whether one module suffices or you need customization.

• Use cases that fit: agency/client sites with frequent nav churn, multi-locale marketing sites, internal admin-console navigation, and content teams that need to launch landing pages under existing menus.

Adoption signal is the headline risk: 0 stars, 0 dependents, 0 composite score, with a modest opportunity score (25.49). Only ~25% of that signal suggests unmet demand — the rest is absence of validation. Additionally, the repository URL resolves to a sibling module (forum-module), which conflicts with the navigation description. Verify the canonical repository and current release activity before treating this as a candidate at all.

When to Consider This Package

Consider it when:

• You are already on the Streams Platform / PyroCMS and need editor-facing menu management — the marginal cost is one Composer dependency.
• You need a nested, reorderable link tree with mixed link types and want it in days, not a sprint.
• Your team is small and would rather not own a nav CRUD surface plus its permissions and localization edge cases.
• Navigation is genuinely editor-owned in your operating model — i.e., marketing changes menus monthly, not annually.
• You can pin a version and accept single-vendor upstream risk for a non-critical, easily replaced subsystem.

Look elsewhere when:

• You are on plain Laravel. Pulling a CMS core in for menus inverts the build-vs-buy math.
• You need a headless or API-first navigation source consumed by Next.js/Nuxt/mobile — evaluate whether this module exposes menus outside its own rendering layer, and assume it does not until proven.
• You need nav experimentation: A/B-tested menus, scheduled nav changes, per-segment variants, or analytics-instrumented link ordering.
• You need enterprise controls: approval workflows, nav change audit history, or per-tenant isolation guarantees.
• Maintenance responsiveness matters more than feature fit. Zero dependents means zero community backpressure; you will be the only ones finding the bugs.
• Performance at scale is a hard requirement — deeply nested trees rendered per request need caching you will own regardless.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, purpose-built module that lets content teams edit site navigation themselves instead of filing engineering tickets. If we are already on the Streams Platform, it is close to free and removes a recurring tax on the engineering team; if we are not, adopting it means adopting a CMS framework to solve a menu problem, which is the wrong trade. Recommendation: evaluate only inside a Streams Platform decision, not as a standalone bet. The package shows no community traction and the repository metadata is inconsistent, so treat it as a vendor-supplied component with a real, if modest, exit cost — the menu and menu-link tables are simple enough that we could rebuild the equivalent in about a sprint if the vendor stalls.

For engineering (the honest version): It is a Streams Platform module, not a general Laravel package — expect to pull the platform core, register a service provider, and inherit its conventions and upgrade cadence. The domain model is unglamorous and portable: named menus, a link tree with ordering, typed link targets, and an admin UI. Confirm PHP/Laravel version compatibility against our stack, confirm whether menus are reachable through any API surface, and confirm the canonical repo — the index we pulled points at forum-module, which is a different module entirely. Because the data model is simple, the migration-away plan is credible: export the menu trees, reimplement the admin screen, keep the same URLs. That portability is the main reason this is a low-risk trial and a poor long-term dependency.