Laravel Uuid Laravel Package

Product Decisions This Supports

• Primary key strategy (UUID vs. auto-increment): the core decision this package serves — whether Eloquent models should expose non-sequential, globally unique identifiers instead of integers. That is a schema-level, high-regret-cost decision that touches API contracts, analytics, support tooling, and data migration.
• Public-facing identifiers in APIs and URLs: UUID PKs prevent ID enumeration and scraper-driven data harvesting, and let you issue IDs client-side before a record is persisted. Relevant to any roadmap item exposing resources to third parties or untrusted clients.
• Distributed writes and data consolidation: merging records across environments, regions, or acquired systems; offline/occasionally-connected clients generating their own IDs; multi-database or sharded write paths where a central sequence is a bottleneck.
• Multi-tenancy and privacy work: GDPR/CCPA data portability and account-merge flows are materially simpler when IDs are globally unique and non-guessable, and when rows can be exported and re-imported without collision handling.
• Build vs. buy (the real decision here): the realistic comparison is not "this package vs. nothing," it is this package vs. Laravel's native HasUuids/HasUniqueStringIds traits vs. ~40 lines of in-house trait. Given the package's status, the build side of that equation is genuinely cheap — this is a pattern decision, not a procurement one.
• Use cases where it maps cleanly: legacy Laravel 5.x–8.x applications that need UUID primary keys on Eloquent models, correct route-model binding, and $incrementing/$keyType/$keyType boilerplate handled in one place.

When to Consider This Package

Consider it only in a narrow, well-understood situation:

• You are on Laravel 8 or earlier, where HasUuids does not exist, and you want a working reference implementation of UUID primary keys for Eloquent rather than writing the trait yourself.
• You need a compact, readable specification of the required model incantations — a design reference for your team's own base model or trait, not a runtime dependency.
• You are comfortable vendoring or forking the code. The MIT license permits this, and the surface area is small enough to audit in an afternoon.

Look elsewhere — i.e., treat this as not adoptable as a dependency — when any of the following hold:

• You are on Laravel 9+. Use the framework-native HasUuids trait and uuid/ulid migration column types. Zero third-party risk, actively maintained, same semantics.
• Index or write throughput matters. Random UUIDv4 primary keys cause B-tree fragmentation on clustered indexes (notably MySQL/InnoDB). Prefer ULID or UUIDv7, which are time-sortable, and evaluate storage cost: 36-byte char vs. 16-byte binary.
• You need current framework or PHP support. Last release was 2020-11-10 and the repository is archived; it predates Laravel 9/10/11 and modern PHP 8.x conventions. Assume incompatibility until proven otherwise.
• You require vendor support or security patching. Archived means no fixes, no CVEs, no responses. A transitive dependency you cannot get patched is a liability in any regulated or customer-facing system.
• You need ULID/UUIDv7 support, binary UUID storage, or ORM-agnostic behavior. None of that is here.
• You would otherwise rely on community validation. 1 star, 0 dependents, and an archived state mean effectively no peer review and no ecosystem precedent to lean on.

How to Pitch It (Stakeholders)

For executives (one paragraph): We need a decision on identifier strategy — whether records are keyed by sequential numbers or globally unique IDs — because it shapes our API contracts, data-merging options, and privacy posture for years. This specific package is not something I recommend we take on as a dependency: it was published by a company as an internal utility, has a single star, no downstream users, no release since 2020, and is archived. The good news is the decision is cheap to act on — the modern Laravel framework ships this capability natively, so we can make the product-level call on identifier strategy without adding third-party risk, and without meaningful engineering cost.

For engineering: Treat this repository as a reference implementation and nothing more. Its value is that it shows, in a few dozen lines, exactly what Eloquent requires for non-incrementing string keys: $incrementing = false, $keyType = 'string', key generation in the model's boot method, and the route-binding implications. Do not add it to composer.json. Use HasUuids/HasUniqueStringIds on Laravel 9+, or lift the pattern into a first-party trait we own. If we do adopt UUID keys, agree up front on UUIDv7/ULID for index locality, binary storage where the database supports it, and the migration path for existing integer-keyed tables.

Recommendation: Reject as a dependency. Adopt the pattern via framework-native traits; retain this package only as a citation in our design notes.