Simple Laravel Eloquent Uuid Laravel Package

Product Decisions This Supports

• Identifier strategy (build vs. buy vs. native). UUID primary keys are a legitimate product requirement in a few recurring scenarios: exposing record IDs to external clients where sequential integers leak volume and invite enumeration/IDOR probing; generating IDs on the client or on multiple services without a central sequence; merging datasets across tenants, regions, or acquisitions where auto-increment collisions are a real risk; and offline-first flows where a device must mint an ID before the server sees it.
• Roadmap framing for the "public ID" feature. If a roadmap item is "stop exposing sequential IDs in URLs/APIs," this package is one candidate implementation of that decision — but the decision itself (UUID vs. ULID vs. prefixed ID vs. separate public-ID column) is the product call, and it should be made independently of any package.
• Schema and API contract commitments. Choosing UUID primary keys is close to irreversible: it changes index size, join performance, URL shape, sorting semantics, and client expectations. A PM should treat this as a platform decision gated on measured write throughput and storage cost, not a per-model convenience.
• Buy/borrow assessment outcome: not this package. For the decision "do we adopt UUID keys," the recommended path is framework-native (HasUuids, available in modern Laravel) or a ~15-line in-house trait. This package does not meaningfully shorten the work, so it should not appear on a build-vs-buy comparison as a "buy" option.
• Not a fit for: new greenfield work on a supported Laravel version, or any codebase with a dependency-review or security-review gate — see below.

When to Consider This Package

Adoption criteria — all of these would have to be true simultaneously:

• You are pinned to an older Laravel version (pre-9, effectively) that predates the native HasUuids concern, and upgrading is not on the near-term roadmap.
• You want a drop-in trait with zero configuration rather than writing the trait yourself (the in-house version is roughly: set $keyType = 'string', $incrementing = false, and a creating hook assigning (string) Str::uuid()).
• You have verified compatibility against your exact Laravel and PHP versions — the last release is 2020-07-14, which predates Laravel 9/10/11, PHP 8.x, and the HasUuids/HasUniqueStringIds concerns. Absent a passing test run, assume it is unverified.
• You have accepted the maintenance risk: 13 stars, single maintainer, no release in ~5 years. In practice this means forking or vendoring the trait rather than depending on the Packagist entry.

Look elsewhere (or build in-house) when:

• You are on Laravel 9+ — use the framework trait; it is maintained by the core team and supports ordered UUIDs, which matter for index locality.
• You need UUIDv7 / ULID / ordered UUIDs for write-heavy or time-sortable tables. Random v4 primary keys fragment B-tree indexes; for high-insert tables the honest options are ULIDs, ordered UUIDs, or a UUID secondary unique column while keeping a bigint primary key.
• You need binary/compact UUID storage (16-byte column) for storage efficiency — that requires a custom cast and column type, not a simple trait.
• You have strict dependency governance: an unmaintained, low-adoption package that hooks Eloquent's creating event is a supply-chain and upgrade-blocking liability disproportionate to the ~15 lines it saves.
• You need foreign-key and relation correctness guarantees across many models — a hand-rolled trait you own is easier to reason about and test than a third-party one you must audit.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed community trait that assigns UUIDs to Eloquent model IDs so records don't expose sequential numbers. The product rationale for UUIDs is real but narrow — public-facing IDs, multi-source data merging, client-generated IDs. The important finding is that the underlying capability is now built into Laravel itself, so the strategic recommendation is not to add this dependency. Adopting an unmaintained 2020 package to save a few lines of code introduces upgrade and security-review friction with essentially no offsetting benefit. Recommendation: no adoption; use the framework feature, or write and own a short trait. Net engineering cost is negligible either way, and the decision that actually needs executive input is the schema/API one — whether we commit to non-sequential public identifiers, with its known indexing trade-offs.

For engineering: Treat this as obsolete-by-default. The last release predates Laravel 9's HasUuids, so the package's entire value proposition is now a first-party feature; on older versions the trait is trivial to write and test in-house. Any adoption should be a vendored/forked copy with a compatibility test against our Laravel and PHP matrix, not a Composer dependency — a single-maintainer package that hooks the creating event and may collide with native HasUuids/HasUniqueStringIds or our own $keyType conventions is an avoidable upgrade hazard. If we do go UUID-primary in places, pair the decision with explicit guidance on ordered UUIDs vs. ULIDs for insert-heavy tables, a plan for relation/foreign-key columns, and a compact-storage option if index bloat shows up in production metrics.