- How do I install and use jamesh/laravel-uuid in a Laravel model?
- Install it with composer require jamesh/laravel-uuid, then add the package's trait to any Eloquent model that needs a UUID primary key. The trait hooks the model's creating event, assigns the UUID, and flips $incrementing to false and $keyType to string. You still need to create the id column as a string UUID type in your migration. There is no service provider or config file to publish.
- Does jamesh/laravel-uuid work with Laravel 9, 10, or 11?
- The package targets Laravel 6 and above, but it has been archived and unmaintained since February 2022, so Laravel 9, 10, and 11 are not supported or tested. Laravel 9+ ships the first-party HasUuids trait, which covers the same behavior. On those versions, use the native trait instead of adding this dependency.
- What UUID version does jamesh/laravel-uuid generate?
- The package is a small trait with no configuration, so the UUID version is fixed in its code. Given its 2022 vintage, it almost certainly generates random UUIDv4 identifiers. Check the trait source to confirm, especially if you need time-ordered UUIDv7 or ULID behavior.
- Should I use jamesh/laravel-uuid or Laravel's built-in HasUuids trait?
- For Laravel 9 and later, use Illuminate\Database\Eloquent\Concerns\HasUuids instead of this package. It provides first-party support for UUID primary keys and is maintained with the framework. jamesh/laravel-uuid only makes sense for legacy Laravel 6 to 8 apps that cannot use the native trait. Do not apply both traits to the same model, because their boot hooks and key settings can conflict.
- What column type should I use for UUID primary keys with this package?
- Use CHAR(36) or VARCHAR(36) for string UUID primary keys, and make foreign keys match the parent column type exactly. A length or collation mismatch can cause subtle join and constraint failures. The package does not validate or create your schema for you, so the migration is your responsibility.
- Does jamesh/laravel-uuid work with binary(16) UUID columns?
- The package's stated scope is assigning a UUID to the primary key and switching Eloquent to a non-incrementing string key. It does not provide binary(16) conversion casts or schema tooling. If you want binary storage, you must add your own casts and accept extra debugging overhead. Confirm the trait's behavior in source before relying on it.
- Will jamesh/laravel-uuid overwrite an ID I set manually?
- The trait assigns a UUID in the model's creating event, and the package does not document whether it checks for an existing id first. If it overwrites unconditionally, imports and fixtures that set their own IDs will break. Read the trait source or write a test that sets id manually before saving. This is a small enough behavior to verify and patch in your own copy.
- Is jamesh/laravel-uuid maintained, and is it safe for production?
- No. The repository is archived, unmaintained since February 2022, and has roughly 20 stars and zero dependents. It has no network, filesystem, or auth surface, so supply-chain exposure is minimal, and its MIT license makes forking or vendoring clean. The real risk is behavioral: untested edge cases on modern PHP and Laravel versions, plus silent UUIDv4 index costs.
- Can I use jamesh/laravel-uuid with route model binding and JSON responses?
- Route model binding works with UUID keys as long as the id column is a string type and $keyType is set to string, which the trait does. JSON serialization also works because the key is a normal string attribute. The package does not add any special binding or serialization logic, so test both in your app. If you use binary(16), you need casts before either will behave correctly.
- What are the alternatives to jamesh/laravel-uuid?
- On Laravel 9+, the native HasUuids trait is the direct alternative and should be your default. For legacy Laravel 6 to 8 apps, vendor a small internal trait into your own app/Concerns namespace with your own tests. If you need time-ordered keys, evaluate UUIDv7 or ULID instead, because random UUIDv4 primary keys cause page splits and index fragmentation on MySQL InnoDB.