Laravel Uuid Laravel Package

Product Decisions This Supports

• Identifier strategy for public-facing entities. Choosing between auto-incrementing integers and UUIDs for models exposed in APIs, URLs, or emails — the decision hinges on non-enumerability, IDOR/security exposure, and not leaking record volume to competitors.
• Build vs. buy (vs. copy). This package is a candidate for the "buy" column, but its real function is to make the build decision cheap: it encapsulates the "generate an ID on creating" behavior that is otherwise ~15–40 lines in a base model. The PM decision is whether that belongs in a dependency, a shared internal trait, or is already covered by the framework.
• Secondary-key migration pattern. If the package supports a uuid column alongside an existing integer primary key (rather than replacing the key), it enables a phased rollout: add a nullable uuid, backfill, switch route model binding, keep integer FKs for join/index performance. That is a roadmap-relevant, low-risk adoption path for existing schemas.
• Distributed and offline-created records. UUIDs let clients, queues, or partner systems mint IDs before a round-trip to the database — relevant for import/sync features, mobile offline drafts, and multi-tenant data merges (e.g., post-acquisition consolidation).
• Feature/use-case fit: public share links, webhook and event payload IDs, idempotency keys, audit-log correlation, anything where a client must reference a record before the server has assigned one.

When to Consider This Package

Consider it when:

• You are on an older Laravel version without native UUID traits, and you want a minimal, isolated implementation rather than hand-rolling one in each model.
• You specifically need a secondary uuid column next to an integer primary key — Laravel's built-in HasUuids replaces the primary key, so the "keep fast integer PKs, expose opaque public IDs" pattern often still needs custom code.
• You need the behavior on a small number of models and are willing to read ~100 lines of source before merging.

Look elsewhere (or don't adopt) when:

• You are on Laravel 9+ and only need UUID primary keys — use the framework's HasUuids; for sortable keys use HasUlids. A third-party dependency buys nothing here and adds an upgrade liability.
• You need UUIDv7, ULIDs, Snowflake IDs, or ordered/time-sortable variants beyond what's offered — go directly to ramsey/uuid or symfony/uid.
• You need composite IDs, per-tenant UUID namespaces, or deterministic (name-based v5) IDs for deduplication.
• Adoption-signal check: zero stars, zero dependents, and a single maintainer is a maintenance-risk red flag. With this little surface area, the correct move is usually to vendor the trait into your codebase (with attribution and a test) rather than add a Composer dependency you'd have to audit on every Laravel major. Blast radius is genuinely low either way — it's a creating hook, easily replaced.
• If the package is unmaintained and untested against your Laravel version, do not put it on a critical path without a local fork and a regression test.

How to Pitch It (Stakeholders)

For executives (1–2 sentences): "This is a very small utility that lets our records use non-guessable public identifiers instead of sequential numbers — reducing the risk of someone scraping or tampering with records by incrementing an ID in a URL. Cost is near zero and it's removable in an afternoon if we change direction; the honest recommendation is to copy the technique internally rather than depend on a package with no adoption."

For engineering: "It's a trait that assigns a UUID on model creation. Before adopting: (1) confirm the installed Laravel version doesn't already cover this via HasUuids/HasUlids; (2) confirm whether we want a UUID primary key or a UUID secondary column — we almost certainly want the latter for index performance; (3) if we proceed, vendor the trait into app/Models/Concerns with a unit test and a backfill migration, rather than adding a zero-adoption dependency. Estimated effort: half a day including backfill and route-model-binding switch; rollback is a config change."

Decision requested: approve the identifier strategy (UUID secondary keys for public-facing models) and the delivery approach (internal trait, not a third-party package), not the package itself.