Weave Code
Shortid Doctrine Bundle Laravel Package
pugx/shortid-doctrine-bundle
Symfony bundle that integrates PugX ShortId with Doctrine ORM, giving entities short, unique, human-friendly identifiers generated automatically on persist. Ideal for clean URLs and readable public IDs.
Symfony bundle for ShortId Doctrine type
Frequently asked questions about Shortid Doctrine Bundle
- Is pugx/shortid-doctrine-bundle a Laravel package?
- No. It is a Symfony bundle that integrates pugx/shortid-php with Doctrine ORM to generate short, unique, human-friendly entity IDs. It has no Laravel service provider, facade, publishable config, or Eloquent integration, so it should be evaluated as a candidate PHP dependency rather than a Laravel package.
- Can I install pugx/shortid-doctrine-bundle directly in a Laravel application?
- Not as a drop-in. The bundle's value is a Doctrine custom ID generator wired through Symfony's DI container, and neither half is present in a standard Laravel app. A viable path is to depend on pugx/shortid-php directly and build a small Laravel-native adapter, which is closer to a one-to-two-day spike than an install.
- Does this bundle work with Eloquent?
- No. Laravel's default persistence layer is Eloquent, while this bundle targets Doctrine ORM entity ID generation. If you are Eloquent-first, evaluate sqids/sqids or hashids/hashids for opaque public IDs, or write a small trait or column strategy yourself.
- What if my Laravel app already uses Doctrine via laravel-doctrine/orm?
- That is the only realistic fit. You can use the bundle's generator class with laravel-doctrine/orm, but you would still skip the bundle's Symfony DI wiring and register an adapter through the Doctrine config. Confirm the package's PHP floor and Symfony component constraints resolve against your Laravel version before committing.
- How do I generate short, URL-safe public IDs in Laravel without this bundle?
- Depend on pugx/shortid-php directly, or use sqids/sqids or hashids/hashids if you only need opaque IDs. Implement generation behind an interface and persist the result in a dedicated public ID column. That keeps the ID strategy swappable and avoids tying your domain model to a Symfony bundle.
- Does v1.3.1 add Laravel support or change how IDs are generated?
- No. v1.3.1 is a single-line maintenance fix for a Symfony 8 deprecation and carries no API or behavioural change. It is a positive maintenance signal, but it does not change the stack-mismatch decision for Laravel.
- Laravel ships Symfony 7.x components; does a Symfony 8 fix in this bundle matter?
- It is harmless today but tells you the bundle's release cadence is paced by Symfony majors, not Laravel's. Check composer.json constraints explicitly rather than inferring Laravel compatibility from the Symfony 8 fix. A Symfony 8-oriented constraint can conflict with the Symfony components in your Laravel version.
- What are the production risks of adopting short IDs for entities?
- The main risk is irreversibility: once a short ID format is in public URLs, stored in external systems, or shared with partners, changing it is painful. Decide the length, alphabet, and collision budget before the first production write, and avoid leaking the generator into persisted foreign keys. Short IDs are cheap to reimplement, so lock-in is low if you keep the strategy isolated.
- How should I test a short ID strategy in a Laravel application?
- Unit-test your adapter for format, alphabet, length, and collision handling, and integration-test that IDs persist and round-trip through URLs. Avoid asserting exact generated values because they are intentionally opaque and may change with configuration. Make the format decision before the first production write, because public short IDs become a contract once they are shared.
- What alternatives should Laravel developers evaluate instead?
- For Eloquent-first apps, start with sqids/sqids and compare hashids/hashids; both reach the opaque-public-ID outcome with less impedance. For Doctrine-backed Laravel apps, use pugx/shortid-php with a small laravel-doctrine adapter rather than installing this Symfony bundle. Treat this bundle as a source of one generator class and a comparison point, not a supported Laravel dependency.
Weaver
How can I help you explore Laravel packages today?