Nova Sluggable Laravel Package

Product Decisions This Supports

• Ship vs. defer editor-facing URL control. The recurring cost is concrete: content editors who file engineering tickets to fix a slug, or who can't correct a broken public URL without a deploy. This field moves generate/regenerate/edit into the Nova form, converting a stream of low-value tickets into a form field. The decision it unlocks is "content editors own their URLs."

• Build vs. buy on a small affordance — and the honest answer is often "neither." Buy is one MIT composer require; build is roughly 1–3 engineer-days plus ownership. But the strongest option is frequently use Nova's first-party Slug field, which ships with Nova 4+ and tracks Nova releases automatically. The real product decision isn't "this package vs. custom code" — it's "does anything beyond native justify a new dependency at all?"

• Roadmap unblocker for any URL-bearing surface. Relevant wherever public URLs matter: articles, product and category pages, landing pages, campaign links, docs sections. If any of those are on the near-term roadmap, this removes a known editorial friction point at near-zero acquisition cost — but only on the admin-form path.

• A gating item on admin-layer strategy, not a strategic bet. Treat it as replaceable convenience. Before it reaches a roadmap, two boxes must be checked: (a) Nova major-version compatibility confirmed on a branch, not from the README, and (b) Nova's native Slug field demonstrably misses an editorial requirement. If native closes the gap, the correct decision is to add no dependency.

• An explicit scope boundary to socialize upward. The field is admin-form only. It does not generate slugs for API writes, imports, seeders, or queued jobs. Any assumption that "slugs are handled" must be underwritten by a model-level slug trait, or those surfaces silently produce null or duplicate slugs — a correctness bug with SEO consequences, not a UX nicety.

• A forcing function on a bigger question. Zero dependents, 45 stars, and a last release in May 2024 make this a useful signal: is Nova itself a long-term platform commitment, or are we accumulating small, unmaintained field dependencies that will each need a migration? That is genuine roadmap input, not a procurement footnote.

When to Consider This Package

Adopt when:

• You are already on Laravel Nova — the package is inert outside it — and the Nova license is sunk cost you intend to keep paying.
• Nova's native Slug field has been checked against written acceptance criteria and misses something your editors actually need. Default to native until proven otherwise.
• You already use, or will adopt, a model-level slug trait (e.g. spatie/laravel-sluggable) so uniqueness, persistence, and non-UI generation paths are covered. This package is the control surface, not the engine.
• The 1–3 dev-days saved clearly exceeds the cost of vetting and periodically re-verifying a low-adoption dependency.
• You are willing to fork. MIT licensing makes vendoring the field into app/Nova/Fields a legitimate, pre-agreed fallback rather than a failure mode.

Look elsewhere or build in-house when:

• You are not on Nova. Use a model trait plus a plain text field, or Filament's built-in slug field.
• Nova's first-party Slug field already satisfies the acceptance criteria. This is the most likely outcome, and it ends the evaluation.
• You need multi-language slugs, per-locale uniqueness, slug history, or automatic 301 redirects on change. Those are product features with real scope; a form field cannot carry them.
• Your Nova or Laravel version postdates the May 2024 release. Nova majors break fields regularly — assume you will author the compatibility patch or fork.
• Procurement or security review requires a maintained dependency with a named support path. Zero dependents means no community backstop and no "someone already hit this bug" safety net.
• Slug behavior must be identical across admin, API, and import surfaces — then the model trait is the source of truth and the field is optional polish at best.

How to Pitch It (Stakeholders)

To executives: A small, free (MIT) add-on for our Laravel admin panel that lets content editors set and regenerate SEO-friendly URLs themselves instead of filing engineering tickets. Cost is a short evaluation spike — no license, no headcount, no infrastructure. Two caveats we should state up front: maturity (45 stars, zero known dependents, last release May 2024) and redundancy (Nova now ships a comparable built-in field). We would therefore treat it as a swappable convenience layer, keep the actual slug logic in our own model code, and be able to drop or fork it at any time without losing functionality. Recommendation: a one-resource pilot behind a short spike, not a platform commitment.

To engineering: A Nova field that wraps slug generation in the admin form — deriving a slug from a source attribute with a regenerate control — and should delegate uniqueness and persistence to the model's existing slug trait. Integration is a composer require plus registering the field on the relevant resources. Ask for a half-day spike to: (a) confirm compatibility with our Nova major and that the compiled field assets actually render — a blank field after a Nova upgrade is the classic failure here; (b) confirm Nova's native Slug field doesn't already close the gap; (c) confirm the slug trait covers the API, import, and seeder paths the field will not touch; and (d) decide between adopting upstream, vendoring the field into app/Nova/Fields, and reimplementing. The surface area is small enough that all three are viable, and the MIT license keeps the fork open. If we adopt, ship a pinned Composer constraint and a CI smoke test that renders the resource form in the same PR — that check is what turns a silently broken admin form into a build failure.