- Can I use kherge/uuid-bundle in a Laravel application?
- No. kherge/uuid-bundle is a Symfony 2 bundle and relies on Symfony's bundle registration in AppKernel and XML/YAML service container definitions, neither of which exists in Laravel. Laravel has no bundle-loading mechanism, so there is no install-and-use path. Even if you forced the install, you would get a runtime fatal error rather than working UUID generation.
- Why does composer require kherge/uuid-bundle fail on a modern Laravel project?
- The package pins Symfony 2.x and PHP 5.x constraints, which conflict with the symfony/* ^6 or ^7 components required by Laravel 10 and 11 and with PHP 8.1+. Composer will refuse to resolve the dependency graph. Using --ignore-platform-reqs only trades a clean Composer failure for a runtime fatal error, so do not do it.
- What is the Laravel equivalent of kherge/uuid-bundle?
- Laravel ships UUID support natively. Use Illuminate\Support\Str::uuid() or Str::orderedUuid() for standalone generation, and apply the HasUuids trait on Eloquent models to get automatic key generation with keyType set to string and incrementing disabled. For non-Laravel or standalone PHP code, ramsey/uuid is the maintained alternative.
- How do I add UUID primary keys to an Eloquent model in Laravel?
- Add the HasUuids trait to the model and define the column as a UUID in your migration using $table->uuid('id')->primary(). The trait handles key generation on create, sets keyType to string, and disables auto-incrementing for you. Avoid DB-side UUID() defaults so the schema stays portable across MySQL, PostgreSQL, and SQLite.
- Is kherge/uuid-bundle maintained or safe for production?
- No. The repository is archived, Symfony 2 reached end-of-life in January 2019, and the package has 2 stars and 0 dependents, meaning no community validation and no security response capability. Any vulnerability in its pinned transitive dependencies is permanently unpatchable. It should not be used in production under any circumstances.
- What should I do if kherge/uuid-bundle is already in my composer.json during a Symfony-to-Laravel migration?
- First grep composer.json and composer.lock to confirm it is actually referenced, then remove it and run composer update to surface any real coupling. Treat the package as a signal that a UUID requirement exists rather than something to port. Replace the generation calls with Str::uuid() or the HasUuids trait, update models and migrations, and backfill existing rows in a separate, reversible migration.
- Should I use UUIDs, ordered UUIDs, or ULIDs for Laravel database keys?
- Random v4 UUIDs fragment B-tree indexes, which hurts write performance at scale. If sortable identifiers matter, use Str::orderedUuid() or switch to ULIDs with the HasUlids trait. This is the decision point most teams get wrong when replacing a UUID package, so choose deliberately based on your index and ordering requirements.
- How do I test that UUID generation works correctly in Laravel?
- Write a feature test that creates a model and asserts the generated key matches a UUID pattern, for example with Str::isUuid() or a regex assertion. You can also assert the expected version and variant bits if you depend on v4 or v7 semantics. Add a separate assertion that the key column type is string and that incrementing is false on the model.
- How much work is it to fork kherge/uuid-bundle and port it to Laravel?
- Far more than the functionality is worth. You would need to strip the Symfony DI wiring, rewrite it as a Laravel service provider, update Composer constraints from Symfony 2.x and PHP 5.x to a Laravel 10 or 11 plus PHP 8.1+ matrix, and build a test suite from scratch. That is net-new development to reimplement something Laravel already provides for free.
- What are the best alternatives to kherge/uuid-bundle for Laravel developers?
- Use Laravel's first-party tooling: Str::uuid(), Str::orderedUuid(), and the HasUuids trait, or HasUlids if you want time-sortable identifiers. For framework-agnostic PHP code, ramsey/uuid is the maintained and widely adopted library. All of these are actively maintained, compatible with supported PHP and Laravel versions, and require no fork or custom service provider.