Uuid Bundle Laravel Package

Product Decisions This Supports

• Framing the UUID requirement, not the package: This bundle exists to answer a single product question — "should our entities use UUIDs instead of auto-increment integers?" That decision (opaque IDs, distributed ID generation, non-enumerable URLs, client-side ID minting before persistence) is still worth making deliberately. The package itself does not materially inform it.
• Build vs. buy vs. adopt: Treat this as a do-not-adopt data point. It is archived, targets Symfony 2 (end-of-life since 2018), has 2 stars and 0 dependents — effectively no production signal. Any roadmap item that depends on it should be re-scoped onto a maintained equivalent (ramsey/uuid for the library, symfony/uid for Symfony-native Uuid/Ulid types, or a thin custom service provider in Laravel).
• Stack fit is wrong by default: The package is a Symfony 2 bundle, not a Laravel package. There is no service provider, no facade, no config/uuid.php. In a Laravel codebase it would at best be an unused library dependency; the bundle wiring (DI extension, services.xml) is dead weight. This should be recorded in the build-vs-buy matrix as "incompatible by architecture," not "low quality."
• Feature pattern still reusable: The underlying pattern — inject a UUID generator as a service, expose it to entities/models, and let the domain request identifiers rather than the ORM — is a valid design. Copy the pattern into a small UuidGenerator interface bound in a service provider; do not copy the code or its Symfony 2 idioms.
• Migration/audit signals: If this package appears anywhere in a dependency tree (legacy Symfony 2 app being acquired, inherited codebase, due-diligence review), that is a red flag for an unmaintained stack, not just an unmaintained library. Escalate it as a platform-modernization finding rather than a dependency bump.

When to Consider This Package

Adoption criteria — all of which must hold, and in practice none do today:

• You are running a Symfony 2.x application that is frozen and will not be upgraded, and you need a drop-in UUID service with minimal integration work.
• You have verified the bundle installs against your exact Symfony 2 minor version and the Composer constraints still resolve (the archive status means no future fixes for PHP 8+ deprecations or security-relevant changes in dependencies).
• The UUID use is non-critical — no reliance on it for security-sensitive unguessability guarantees, no compliance requirement around ID generation, and no expectation of long-term support.
• You accept that you are vendoring effectively unmaintained code, with a plan to fork and own it.

Look elsewhere when:

• You are on Laravel at all — use ramsey/uuid or Laravel's native HasUuids / HasUlids traits; there is no reason to bridge a Symfony bundle.
• You are on Symfony 4+ — use symfony/uid, which is first-party and maintained.
• You need ULIDs, sortable UUIDs (v6/v7), UUID validation, Doctrine type mapping, or route/param conversion — none of that is scoped here.
• You need any form of support, security patching, or a maintained release cadence. The archive flag alone disqualifies it for anything customer-facing.
• You are evaluating dependency risk for an acquisition or security review — the correct recommendation is removal/replacement, not adoption.

How to Pitch It (Stakeholders)

For executives: This is a 2-star, archived Symfony 2 add-on with zero downstream users. It solves a real problem (using UUIDs as primary keys) but does so on a framework generation that has been unsupported for years, and it does not fit our Laravel stack at all. Recommendation: do not adopt. The UUID decision itself is still worth making, and we can satisfy it with first-party/actively maintained libraries at negligible cost — roughly a day of engineering, no new vendor risk, no maintenance obligation.

For engineering: The package is a Symfony 2 bundle wrapping a UUID library via DI configuration. In Laravel it contributes nothing — no service provider, no config surface — so "adopting" it means adding an unmaintained transitive dependency and writing our own wiring anyway. Use ramsey/uuid (or symfony/uid if we ever add Symfony components) behind a small UuidGenerator interface bound in a service provider, and use Laravel's HasUuids/HasUlids model traits where the ORM should own ID generation. If we want the bundle's design intent, mirror the pattern — generator as an injected service, domain requests IDs rather than the ORM — not the code.

One-line ask: Approve closing this evaluation as "rejected — archived, wrong framework generation, incompatible with Laravel," and log the UUID-as-primary-key decision as a separate, still-open product question.