Filament Link Picker Laravel Package

Product Decisions This Supports

• CMS / page-builder roadmap: The field lets editors choose a named Laravel route rather than pasting a URL. That supports decisions about whether to expose route-based linking in admin, and whether to store links as route name + parameters instead of a raw string — a modeling choice that makes URLs refactorable and localization-friendly.
• Build vs. buy: This is a narrow UI primitive, not a platform. Building an equivalent Filament field is days of work plus ongoing Filament-upgrade maintenance. Adopting or forking is the rational default if the fit is close; "build" only makes sense if you need a richer link object (models, external URLs, UTM, signed links).
• Feature prioritization: Supports "editorial self-service" and "link integrity" initiatives — fewer broken links, fewer engineering tickets to change nav/CTAs, better SEO hygiene. Good candidate for a small, measurable improvement rather than a roadmap centerpiece.
• Concrete use cases: Header/footer/navigation menus, marketing CTAs, in-app announcement banners, documentation cross-links, internal links in email templates. Poor fit for user-generated external links or link-governance workflows.
• Link governance decisions: Because route names are stable identifiers, this can feed link-checking jobs, redirect generation after URL changes, and analytics decoration. It does not itself provide redirects, auditing, or link resolution — those remain product decisions.
• Risk posture decision: 1 star, 0 dependents, single maintainer, MIT license, recent release (2026-07-22). The package is small enough that the decision is "vendor/fork and own it," not "bet the platform on it." Avoid making it critical-path without an internal owner and tests.

When to Consider This Package

Consider it when:

• Your stack is Laravel + Filament and you need an admin field for selecting internal application routes.
• You want non-technical editors to pick from available routes without typing URLs or asking engineering.
• You can accept a small, MIT-licensed, single-maintainer package — and are willing to pin the version, vendor/fork it, and test on Filament upgrades.
• The scope is internal navigation and CTA linking, not full link management.
• The blast radius is contained: a form-field-level UI concern, not runtime request handling or public API surface.

Look elsewhere when:

• You are not on Filament, or need a framework-agnostic link field.
• You need to link to Eloquent models or CMS pages (a polymorphic "page picker") rather than named routes.
• You need external URL validation, UTM builders, affiliate/tracking links, or link shorteners.
• You require localized route names across locales, signed URLs, route-model-binding parameters, or a richer link resolver.
• You need enterprise support, SLAs, or a package with an active community — 1 star and 0 dependents are maturity signals, not disqualifiers for a tiny utility, but they mean upstream responsiveness is not something to rely on.
• You need audit trails, broken-link monitoring, redirect management, or permissioned link approval — this is a picker, not a governance system.
• The route list is very large; verify search/pagination behavior before committing.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Filament field that lets content editors pick internal routes instead of pasting URLs. It is cheap to adopt and targets a real operational cost: broken links and engineering tickets for nav/CTA changes. Treat it as a UI component, not a platform bet. Because it is tiny and MIT-licensed, exit cost is low — we should vendor/fork it, assign an owner, and measure reduced link-edit tickets and broken-link incidents.

For engineering: It is a focused Filament custom field with a narrow surface area. Integrate it behind our own link-value contract so we can swap implementations later. Add tests for route-name storage, parameter handling, and Filament upgrades. Pin the version and review the release; the single-maintainer, 1-star profile means we should not depend on upstream responsiveness. If localization, parameters, or model-based page picking are missing, a fork is likely trivial. Success looks like fewer broken links, fewer content-ops tickets, and no added upgrade friction.