Uuid Extra Bundle Laravel Package

Product Decisions This Supports

• Identifier strategy for the domain model. Choosing UUIDs as public identifiers instead of auto-increment integers for anything exposed through an API or URL. This package is the plumbing that makes that decision cheap to execute on Symfony: route params become Uuid objects, forms validate them, and the serializer emits them as strings — one consistent contract instead of three hand-rolled conversions.
• Build vs. buy on glue code. Still ~3 small integrations (ParamConverter/ValueResolver, Normalizer, Form Type), still a bounded question: write 150–300 lines of UUID adapters in-house, or take a dependency? The 4.2.0 release marginally improves the "buy" answer because the maintenance signal is no longer zero, but it does not change the scope of the decision.
• API contract and client SDK scope. The Normalizer defines how UUIDs appear in JSON, which feeds API spec work and any client SDK or mobile consumer. Standardizing here removes a class of "sometimes string, sometimes object" bugs.
• Security/enumeration posture. Public endpoints where sequential integer IDs leak volume and invite guessing — UUID-in-URL is often driven by this, and this package determines how much controller-level validation code it costs.
• Back-office and admin tooling estimates. The Form Type gives free UUID validation with user-facing error messages — scope you either get for free or rebuild and retest in every admin form.
• Dependency support-matrix policy (new). 4.2.0 is a support-matrix-only release: it drops older PHP and Symfony. That is precisely the class of change that silently breaks CI or blocks a legacy service from taking a security patch later. A PM call is needed on which pinned minor each service standardizes to, and whether any service is now stranded below the new floor.
• Framework upgrade roadmap (revised). The prior "unmaintained since January 2022, budget a fork" line is retired. The roadmap item changes from fork-or-replace to verify the Symfony 6.2+ ValueResolver story and Ramsey 4.x / UUIDv7 compatibility against the 4.2.0 changelog, then pin.

When to Consider This Package

Consider it when:

• You are on Symfony — this is a Symfony bundle, not a Laravel package, and it does nothing for a Laravel codebase. That constraint is unchanged by 4.2.0.
• You already use ramsey/uuid and have several controllers, forms, and serializer paths handling UUIDs.
• Your app sits on Symfony 5.4/6.x: take 4.2.0, and confirm on the changelog whether it now ships a ValueResolver for 6.2+. If you are still on Symfony 4.4, 4.2.0 is likely out of range — you would pin an older line and accept the unsupported position.
• You want a permissively licensed (MIT), tiny-surface addition rather than a framework-level commitment.
• You value recent release activity as a tiebreaker. Note the caveat: one release after a multi-year gap is a maintenance signal, not a maintenance commitment. You remain the de facto maintainer of your usage.

Look elsewhere when:

• Laravel. Use ramsey/uuid directly with route model binding / HasUuids; this bundle provides zero value there. If the goal is a Laravel-side identifier story, this package is off the table entirely.
• Symfony 6.2+ without confirmed ValueResolver support. If 4.2.0 does not cover the ValueResolver path, you are still writing a resolver and normalizer yourself.
• You need Doctrine column types. That is ramsey/uuid-doctrine, a different package; persistence mapping is out of scope here.
• You need UUIDv7 / time-ordered identifiers. A support-matrix release does not evidence v7 support — verify against the changelog and Ramsey version floor before betting an ID strategy on it.
• You require vendor support or a security response path. There is still no commercial backing or published SLA; a single release does not create one.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed convenience layer that standardizes how UUID identifiers move through our Symfony API — controllers, forms, and JSON output. It saves a few days of engineering and reduces a class of identifier-handling bugs. The prior concern that it was abandoned is largely resolved by the 4.2.0 release, but one release after a long gap is not a vendor relationship. It remains non-strategic: worth a time-boxed trial, not worth standardizing across teams. It is also Symfony-only and irrelevant to our Laravel services.

To engineering: 4.2.0 is a support-matrix release — it drops older PHP and Symfony and describes no features or API changes. Practically: low expected upgrade risk, but check your runtime before bumping, because services on older PHP or Symfony 4.4 may be pinned out entirely. Two open questions from the previous assessment should be re-checked against the changelog rather than assumed: whether it now handles Symfony 6.2+ via ValueResolver, and whether it is compatible with Ramsey 4.x / UUIDv7. Keep it pinned (or vendored if that is already your pattern) and downgrade the fork urgency from "budget now" to "monitor the next two or three releases for cadence." If a release stalls again or your fork friction exceeds roughly a day, write the adapters in-house.