alsofronie/eloquent-uuid
alsofronie/eloquent-uuid adds UUID primary key support to Laravel Eloquent models, with traits that automatically generate UUIDs on create and let models replace auto-incrementing integer keys with minimal configuration.
Architecture fit. The package is a single-purpose Eloquent trait that hooks the model creating event and fills configured UUID columns — an idiomatic Laravel 5.x pattern, architecturally trivial, and roughly 50–100 lines of logic. That is precisely the problem: the capability is now framework-native (HasUuids since Laravel 9, HasVersion7Uuids in Laravel 11), so adopting a third-party dependency buys no architectural leverage and adds supply-chain surface for code that belongs in the app layer or the framework. The low opportunity score (1.14) reflects this: near-zero differentiation versus what a Laravel developer writes in an afternoon.
Integration feasibility. Low for any current stack. Declared support is Laravel 5.1 and 5.2 — both long EOL (5.2 in 2017, 5.1 security support ended 2018) — with a final release in July 2017, which implies PHP 5.5/7.0-era constraints and a ramsey/uuid v2/v3 pin. Composer will almost certainly refuse to resolve against Laravel 9+/PHP 8.x. Forcing it with --ignore-platform-reqs still leaves behavioral assumptions to verify: event-hook registration, $incrementing/$keyType handling, and the UUID factory API (v4 of ramsey/uuid changed factory signatures and return types).
Technical risk. Abandonment risk is high; functional complexity risk is low. There is no meaningful attack surface (no network I/O, no deserialization), but there is also no patch channel. The substantive risk sits in data modeling, not the package: 36-byte char(36) primary keys inflate every secondary index, random v4 inserts destroy B-tree locality on InnoDB, and foreign-key column types must be converted in lockstep. The package also cannot protect against its own bypass — raw insert(), upsert(), DB::table() writes, and non-Eloquent seeders skip model events and will silently produce rows without UUIDs.
Key questions.
uuid, 16 bytes) or MySQL (char(36) vs binary(16))?Stack fit. If the estate is genuinely on Laravel 5.1/5.2, this is a plausible drop-in and the cheapest path to UUIDs. On Laravel 6+, and certainly 9+, it is not a dependency decision at all — it is a "use the framework trait or write the 50 lines yourself" decision.
Migration path. Decide identifier semantics first, because that drives everything downstream. For a UUID primary key: convert the column type, backfill existing rows, set $incrementing = false and $keyType = 'string', migrate all foreign keys, verify route model binding and API serialization, and confirm find()/whereKey() behavior. For a secondary external-ID column: additive nullable migration, backfill, unique index, then tighten to NOT NULL after verification.
Compatibility. The boot<TraitName> convention survives into Laravel 11, so a hand-rolled replacement is a direct port: one static::creating hook, a column list accessor, and Str::uuid() / Str::orderedUuid() or Ramsey\Uuid\Uuid::uuid4(). Watch for conflicts with framework HasUuids if both are introduced during transition, and confirm $guarded/$fillable does not accidentally expose the UUID column to mass assignment.
Sequencing. (1) Inventory models and the FK graph. (2) Choose v4 vs v7/ULID based on write volume. (3) Implement or port the trait with tests covering factory creation, insert, upsert, and seeders — the bypass paths, not just the happy path. (4) Expand/backfill in a shadow phase. (5) Cut over reads. (6) Contract away legacy columns and indexes. Avoid a big-bang column swap on any table with meaningful write traffic.
Maintenance. Effectively zero upstream maintenance; you inherit full ownership. Treat adoption as a fork: vendor the code into the repo, add a regression test, and stop tracking the upstream package as a dependency.
Support. No maintainer, no CVE channel, no issue triage, no version compatibility guarantees. Tolerable only because the code is small and self-contained — this is a "known quantity" risk, not an unknown one.
Scaling. The dominant cost is UUIDv4 primary keys: 36-byte values replicated into every secondary index, plus random insert ordering that fragments B-trees and bloats the buffer pool. This is invisible at low write volume and material at sustained throughput. If the table is insert-heavy, use UUIDv7/ULID or binary(16) storage with string casting at the boundary.
Failure modes. NOT NULL violation on insert when the trait is bypassed; silent null UUIDs from bulk operations (detected only at read/export time); mixed ID types breaking find() and route binding after a partial migration; foreign-key type drift across services; duplicate-key collisions on the UUID column (statistically negligible, but the retry path should exist). Queue workers and imports writing via raw SQL are the highest-probability source of incidents.
Ramp-up. Hours for any competent Laravel developer. The real cost is not learning the package — it is the identifier-strategy decision record, the migration, and the FK/index remediation that follow.
Recommendation. Do not adopt. This is a 2017 artifact scoped to two EOL framework versions, delivering functionality the framework now ships. Replicate the behavior in-house (or use HasUuids/HasVersion7Uuids) and spend the saved effort on the identifier strategy and migration plan, which is where the actual product risk lives.
How can I help you explore Laravel packages today?