Laravel Uuid Laravel Package

Technical Evaluation

Architecture fit. jamesh/laravel-uuid is a single-purpose Eloquent trait: it hooks the model's creating event, assigns a UUID to the primary key, and (per the package's stated scope) flips $incrementing and $keyType so Eloquent treats the key as a non-auto-incrementing string. That is roughly 20–40 lines of code. There is no service provider surface worth speaking of, no configuration, no schema tooling, no storage abstraction. Architecturally it is a leaf dependency that touches the most sensitive part of the persistence layer — primary key generation — while offering nothing you could not write in an afternoon. For a TPM the honest framing is: this is not a library, it is a snippet with a version number.

Integration feasibility. Trivially feasible on Laravel 6–8. On Laravel 9+ it is redundant: the framework ships Illuminate\Database\Eloquent\Concerns\HasUuids (and HasUniqueStringIds beneath it), which covers the same behaviour with first-party support. On Laravel 10/11 the package is untested, unmaintained since February 2022, and archived, so any adoption is a forward-compatibility bet on code nobody is maintaining. Composer install will likely still resolve, but "installs" is not "is supported".

Technical risk. Low blast radius, non-trivial correctness surface. The package has no network, filesystem, or auth surface, so supply-chain and CVE exposure is minimal — and it is MIT, so forking or vendoring is legally clean. The real risk is behavioural: UUIDv4 primary keys are random, and on MySQL InnoDB's clustered index that means page splits, index fragmentation, and degraded insert throughput as tables grow. If the trait defaults to v4 (almost certainly, given its vintage), you inherit that cost silently. Secondary risks are misconfiguration — binary(16) vs CHAR(36) columns, $incrementing/$keyType drift, route model binding, and JSON serialisation — none of which the package validates for you. With 20 stars, 0 dependents, and an archived repo, there is no user base to surface edge cases before you hit them.

Key questions. Which UUID version does it emit, and is generation overridable? Does it respect a pre-set id (important for imports and fixtures) or overwrite unconditionally? Does it handle both string and binary column types, and does it cast correctly? Does it conflict with the framework's HasUuids if both are present? Does it work on PHP 8.1+ without deprecations, and has anyone run it on Laravel 10/11? Is the trait's boot hook name collision-safe alongside other traits? And finally: what is the actual cost of not depending on it?

Integration Approach

Stack fit. Fits Laravel 6–8 only, and only for teams standardising on UUID primary keys. It does not fit Laravel 9+ (use HasUuids), and it does not fit teams who have not yet decided between UUIDv4, UUIDv7, and ULID — that decision should precede any dependency choice, because it determines your index strategy.

Migration path. Do not add this as a new dependency. Three routes, in order of preference: (1) Laravel 9+ — use the native HasUuids trait and delete any thought of the package; (2) Laravel 6–8 — vendor an internal trait into your own app/Concerns namespace, with your own tests, owned by your team; (3) if it is already in the codebase, copy its behaviour into that internal trait, run the suite against both, then remove the Composer requirement. Because it is MIT and archived, forking is a legitimate and cheap exit — but for this little logic, owning the code outright is cheaper than owning a fork.

Compatibility. Verify the id column type end-to-end before anything else: CHAR(36)/VARCHAR(36) for string UUIDs, BINARY(16) only if you also add conversion casts and accept the debugging overhead. Confirm $incrementing = false and $keyType = 'string' land on every model, and that foreign keys match the parent column type exactly — a length or collation mismatch produces subtle join and constraint failures that surface late.

Sequencing. (1) Decide the identifier strategy, including ordered-vs-random. (2) Audit existing models, migrations, and FKs for UUID usage and column type consistency. (3) Write or vendor the internal trait with tests covering creation, explicit-id assignment, route binding, relations, and serialisation. (4) Migrate models behind a feature-flagged branch. (5) Remove the external dependency and, if you have data in production, plan an index rebuild window — random UUID PKs benefit measurably from OPTIMIZE/rebuild after heavy churn.

Operational Impact

Maintenance. Zero. The repository is archived and the last release is February 2022. There will be no PHP 8.x fixes, no Laravel 11 support, no security response. Treat any dependency on it as a permanent fork you have implicitly agreed to maintain without having written down that agreement.

Support. Community-only, and effectively no community: 20 stars and 0 dependents means no issue triage, no Stack Overflow corpus, no third-party blog coverage. Internal escalation path is "read the source", which is viable here only because the source is tiny. That is the package's one saving grace.

Scaling. The identifier choice dominates. UUIDv4 primary keys are random; on InnoDB the clustered index means inserts land at arbitrary pages, causing page splits and write amplification that worsen as the table grows past cache. Read paths are fine — point lookups on a unique index are cheap — but range scans and chronological ORDER BY degrade, and FKs double the storage cost. At small scale this is invisible; at tens of millions of rows it is a migration project. If you are greenfield, push for UUIDv7 or ULID and sidestep the entire conversation.

Failure modes. Most likely first: "no primary key" or null-id errors from a model where the trait did not boot because of a trait name collision or a boot method conflict. Next: column type mismatch producing truncated or malformed UUIDs, or binary/string comparison failures in joins. Then: mass-assignment or import paths overwriting explicit ids, breaking fixtures and data restores. Then: route model binding returning 404 because the key cast is wrong. Finally and least visibly: silent index fragmentation that nobody notices until p95 write latency climbs.

Ramp-up. Hours, not days. A mid-level PHP developer reads the entire package in one sitting and can reimplement it with tests inside a sprint. That is precisely the argument against adopting it: the integration cost is dominated by the surrounding decisions — column types, FK consistency, identifier version, index strategy — not by the trait itself. The package contributes almost nothing to that work while adding an unmaintained artefact to your dependency graph.

Recommendation. Do not adopt. Use Laravel's native HasUuids where available, vendor an internal trait otherwise, and spend the saved effort on choosing an ordered identifier format before the first table is created. Score 0.17 and an archived repository are aligned with that conclusion: this is a snippet that has been packaged, not a library that has been maintained.