Shortid Doctrine Bundle Laravel Package

Product Decisions This Supports

• Identifier strategy for public-facing resources. Whether order numbers, invoice links, share URLs, and support references use sequential auto-increment IDs (enumerable, scrapeable) or short, URL-safe, non-sequential IDs. This package makes the short-ID option a configuration choice rather than a custom-code project.
• Build vs. buy. The package is a thin Doctrine integration over the pugx/shortid library — it supplies a Doctrine ID generator plus bundle config (alphabet, length, custom generator service). Buying here means near-zero code to own; building means writing and maintaining a Doctrine ID generator yourself.
• Exposure/abuse risk reduction. Short random IDs make ID enumeration and bulk scraping of /orders/1..N materially harder — a product-security decision, not just a cosmetic one.
• Upgrade risk tracking. v1.3.1 is a Symfony 8 deprecation fix, which is a compatibility signal: the package is being kept current with the Symfony release train, so it is not a blocker for a Symfony 8 upgrade.
• Use cases well served: shortened public identifiers, human-readable reference codes for support/phone conversations, and prettier URLs than UUIDv4.
• Framework-fit caveat for the roadmap: this is a Symfony/Doctrine bundle, not a Laravel package. On a Laravel/Eloquent codebase it provides no value; the equivalent decision there is a trait or a hashids-style package.

When to Consider This Package

Adopt when:

• The application is Symfony (7.x/8.x) using Doctrine ORM entities.
• You want short IDs as primary keys generated at persist time, configured declaratively rather than hand-rolled.
• You need URL-safe IDs shorter than UUIDs and don't require time-ordering.
• You value a small, single-purpose dependency over a broader "awesome IDs" framework.

Look elsewhere when:

• The stack is Laravel/Eloquent — this bundle does nothing there; use an Eloquent trait or a hashids/ULID approach instead.
• You need sortable/time-ordered IDs — use symfony/uid (UUIDv7/ULID) instead.
• You need reversible encoding of existing integer IDs (e.g., obfuscating legacy records) — that's a hashids problem, not a key-generation problem.
• You need guaranteed uniqueness at high write throughput across distributed writers; verify the collision-handling story before committing, since generation happens in PHP and correctness leans on DB uniqueness constraints.
• You require a large maintainer base or commercial support — this is a small-maintainer package; budget for the (small) exit cost of swapping the ID generator.
• You're mid-launch with existing sequential IDs: switching the PK strategy later is a data migration, so treat this as a pre-launch decision.

On this specific release: v1.3.1 is a patch containing one Symfony 8 deprecation fix (PR #19). No new features, no breaking changes, no API changes. No re-assessment of fit is triggered — only a routine dependency bump.

How to Pitch It (Stakeholders)

To executives: We're standardizing how public identifiers look and behave. This is a small, single-purpose dependency that lets us use short, non-guessable IDs in customer-facing URLs and reference codes instead of exposing sequential database IDs — reducing enumeration and scraping risk at effectively no engineering cost. The just-released v1.3.1 is a maintenance patch that keeps it compatible with Symfony 8, so it will not block our framework upgrade. Risk is low and contained: it's a thin wrapper, and swapping it out later is a localized change.

To engineering: One config block (pugx_shortid) plus an entity annotation/attribute swaps the Doctrine ID generator; IDs are generated in PHP, so no schema or sequence migration is needed to adopt it. v1.3.1 is patch-level — a Symfony 8 deprecation fix only, no behavior change, safe to take in a routine bump. Two things to confirm before we commit: collision handling under our expected write volume, and that we're happy to live with non-sortable PKs (they hurt B-tree locality on high-insert tables). And note the scope: this is Symfony-only — it is not a candidate for our Laravel services.