Basekit Laravel Slugs Laravel Package

Product Decisions This Supports

• Build vs. buy for URL/slug generation. Slugging looks trivial (Str::slug + a column) but the edge cases are not: uniqueness collisions, transliteration of non-Latin titles, slug stability when titles are edited, soft-deleted rows reusing slugs, backfill/migration of existing records, and redirects when a slug changes. This package is a candidate to standardize that logic instead of re-implementing it in every model.
• Roadmap input for SEO and content surfaces. Slugs are the public identifier for blog posts, product pages, categories, and landing pages. Any roadmap item touching public URLs (content CMS, multi-tenant storefronts, i18n routing) inherits a slug decision — decide it once, centrally, rather than per feature team.
• Consistency and platform standards. A first-party-style basekit-* package signals an intended internal standard. Adopting it is a governance decision (one slug behavior across services, one place to patch transliteration bugs) more than a feature decision.
• Scope validation, not yet a commitment. v1.0.0 with a single "initial release" commit tells us the API surface exists but is unproven. This supports a spike and an ADR, not a roadmap line item.

When to Consider This Package

Consider it when:

• You are greenfield on a Laravel app and want a low-ceremony, Eloquent-level slug trait with a v1.0.0 semver contract from day one.
• Your slug requirements are conventional: a source column, a target column, uniqueness, and regeneration on update.
• You are already standardized on the basekit-* family — consistency with siblings outweighs feature-by-feature comparison.
• You need a thin, auditable dependency rather than a config-heavy one.

Look elsewhere (or build in-house) when:

• You need proven history. cviebrock/eloquent-sluggable and spatie/laravel-sluggable have years of production use, large install bases, and documented answers to hard questions (transliteration sets, slug history tables, 301 redirects on change). A 1.0.0 with one commit has none of that.
• Slug changes must preserve old URLs. Verify explicitly whether this package stores slug history or emits redirects — if not, that is a build-vs-buy blocker for any indexed content.
• You require i18n/localized slugs per locale, or multi-tenant scoping of uniqueness constraints.
• Your security or procurement process requires a maintenance track record (release cadence, issue responsiveness, CVE handling). One release is not evidence of any of these.

Adoption gates before production: confirm the maintainer/backing, confirm the trait's behavior on update (does it regenerate, and does that break live links?), confirm a backfill path for existing rows, confirm collision strategy (suffix vs. fail), and pin the version. Treat this as a low-risk pilot on a non-critical model until it clears those gates.

How to Pitch It (Stakeholders)

For executives: This is a small, narrowly scoped Laravel library that handles how URLs are generated from content titles. The strategic value is standardization — one vetted implementation of slug logic instead of a slightly different version in every feature, which is how you end up with broken links and duplicate pages that hurt SEO and support tickets. Cost of adoption is low; cost of getting it wrong is also low, because it is swappable. Recommendation: approve a scoped pilot, not a mandate. Note honestly that the package is brand new (v1.0.0) with a single maintainer surface and no production track record, so we are buying optionality, not de-risking today.

For engineering: A 1.0.0 Laravel package for model slug generation, released 2026-10-03 as an initial release. It gives us a semver-stable API and, if it mirrors the basekit-* conventions, a predictable trait-based integration. Before we commit: (1) evaluate it head-to-head against spatie/laravel-sluggable and cviebrock/eloquent-sluggable on the three things that actually bite — transliteration quality, slug immutability on update, and uniqueness under soft deletes and concurrency; (2) check whether slug history/redirects are in scope, because retrofitting them later is a migration, not a config change; (3) define the backfill for existing rows. Timebox the spike to a day; the decision is reversible but the data migration is not.

One-line ask: fund a one-day spike plus an ADR, and hold the standard until the pilot clears the gates above.