- How do I install ramsey/uuid in a Laravel application?
- Install it with composer require ramsey/uuid, though most Laravel applications already have it indirectly through laravel/framework. Treat the command as an explicit version pin and review the resolved constraint rather than assuming you are adding a new dependency. After installation, generate UUIDs through Uuid::uuid4() or Uuid::uuid7() and bind any shared factory or generator behind an interface.
- Does Laravel already include ramsey/uuid?
- Yes. laravel/framework depends on ramsey/uuid for Str::uuid(), Str::orderedUuid(), and the HasUuids trait, so it is almost certainly already in your dependency tree. The practical question is not whether to adopt it but how to standardize and pin the version you consume. Check composer show ramsey/uuid before adding a duplicate requirement.
- Which UUID version should I use for Laravel primary keys?
- Use UUIDv7 for database primary keys that need time-ordered inserts and better index locality, and use UUIDv4 for public or external identifiers where creation time should not leak. UUIDv6 is available but is mainly a migration path from v1-style ordering and is rarely needed in new Laravel schemas. Decide per entity class and document the choice.
- How do I use ramsey/uuid with Eloquent models?
- Laravel provides HasUuids and HasUniqueStringIds traits, or you can write a custom Eloquent cast around UuidInterface. The trait path is faster but ties generation to whatever UUID strategy your Laravel release uses, while a custom cast or internal generator gives you explicit control. Pair either approach with a deliberate column type, typically $table->uuid() or binary(16) via Uuid::getBytes().
- Is ramsey/uuid compatible with Laravel and supported PHP versions?
- On the 4.x line ramsey/uuid requires PHP 8.0 or newer and has no Laravel-specific constraints, so it works with any Laravel version that supports that PHP baseline. It is framework-agnostic and needs no service container, HTTP layer, queue, or database coupling. The main dependency considerations are brick/math and, until 5.0, ramsey/collection.
- What is breaking in ramsey/uuid 5.0?
- Version 5.0 is slated to remove the deprecated COMB codecs and generator: OrderedTimeCodec, TimestampFirstCombCodec, TimestampLastCombCodec, and CombGenerator. Code that relies on Str::orderedUuid() lineage or those classes should migrate to UUIDv6 or UUIDv7 before the major bump. Treat 5.0 as a planned work item, not an incidental composer update.
- Should I store UUIDs as binary(16) or char(36) in Laravel?
- Laravel's $table->uuid() resolves to char(36) on MySQL and native uuid on PostgreSQL, while ramsey/uuid can produce binary(16) bytes through Uuid::getBytes(). Binary storage saves index space but changes every query's wire format and is a one-way door for existing data. Choose deliberately per table and keep serialization consistent at API boundaries.
- Are UUIDv1, v6, or v7 safe for public-facing identifiers?
- UUIDv1, v6, and v7 embed a creation timestamp, so using them as user-facing identifiers can enable enumeration and reveal signup volume. Prefer UUIDv4 for externally visible IDs and UUIDv7 for internal primary keys. For v1, also use random node providers because the default MAC-address node provider can expose hardware information, even though all-zero MACs are now ignored.
- How do I test code that generates UUIDs in Laravel?
- Because UuidInterface is Stringable and JSON-serializable and the factory, codec, and generator seams are interfaces, you can bind deterministic fakes for tests. A thin internal UuidGenerator interface makes fixtures predictable and keeps application code from calling Uuid::uuid7() directly everywhere. Use that adapter in feature tests and reserve the real generators for integration coverage.
- How should I pin ramsey/uuid in composer.json?
- Set a floor of ^4.9 rather than floating on whatever your lockfile already resolved, and consider an exact 4.9.x pin if you need fully reproducible builds. The 4.7.5 release fixed same-millisecond UUIDv7 collisions, so older resolutions are a real risk. Avoid a too-tight brick/math constraint that could block security patches elsewhere in the dependency graph.