Page Link Type Extension Laravel Package

Product Decisions This Supports

• Unblocking a specific editor workflow, not a platform bet. This package adds a "Page" link type to the Navigation module in PyroCMS/Streams Platform, letting editors point menu items at CMS pages instead of pasting raw URLs. The product decision it supports is narrow: do we let content editors build menus safely without developer involvement?
• Build vs. buy vs. fork. At MIT license and roughly one class of glue code, the honest framing is "buy costs zero, but so does rebuilding." The real decision is whether to adopt as a dependency or vendor/fork the ~single link-type implementation into your own codebase to eliminate an unmaintained upstream.
• Roadmap signal for navigation/link resolution. If you're building on Streams, this is a working reference for the link-type registry pattern — a template for other dynamic link types (product, category, landing page) you may want later. Treat it as a design input, not a dependency.
• Content-governance feature. Dynamic page links mean slug changes and page renames propagate to navigation automatically. That's a decision about reducing broken-link incidents and editorial support tickets — measurable, and worth a small amount of engineering.
• Not a feature differentiator. Zero stars, zero dependents, score 0.18. This does not create competitive advantage; it closes a gap. Don't let it into a roadmap narrative as innovation.

When to Consider This Package

Adopt when all of the following hold:

• You are running PyroCMS 3.x / the Anomaly Streams Platform and have the Navigation module installed — this package is meaningless outside that stack.
• Your editors are currently pasting URLs into nav items and you're seeing broken links after page slug changes.
• You can pin to a specific commit or tag and accept that upstream maintenance is effectively nonexistent.
• Your team is comfortable reading ~one file of PHP to verify behavior before shipping.

Look elsewhere (or build in-house) when:

• You're not on Streams/PyroCMS. For general Laravel menu needs, use a maintained navigation package (spatie/laravel-menu, Filament's navigation builder, or Laravel Nova's menu tooling). This package will not integrate.
• Dependency hygiene is a hard requirement. Zero dependents and low activity mean no security review surface and no community patch path. Vendor the code and own it.
• You need more than page links — role-gated menus, multi-level mega-menus, A/B-tested navigation, or analytics on nav clicks. This package does none of that; scope creep here is a trap.
• You're planning a migration off PyroCMS. Adding a stack-specific extension during a migration increases exit cost for near-zero benefit.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed add-on for our CMS that lets marketing edit the site navigation without engineering tickets, and stops menus from breaking when pages get renamed. Cost is effectively zero; the risk is that nobody maintains the upstream project, so we'd copy the code into our repo and own it — a few hours of work, not a budget line. It is not a differentiator and should not appear in roadmap messaging; it's maintenance relief.

To engineering: One link-type implementation for the Streams Navigation module, MIT, zero dependents, effectively unmaintained. Recommendation: vendor it — copy the link-type class into our codebase, add a test that a nav item resolves to a page and survives a slug change, and drop the Composer dependency. If we do keep it as a dependency, pin an exact commit and add it to the "unmaintained upstream" watchlist. Do not extend it; if we need more link types, implement them against the Streams link-type contract directly so we own the abstraction.