Id Type Laravel Package

Product Decisions This Supports

• Feature delivery: typed identifiers in the domain layer. This package supports replacing primitive int/string IDs with dedicated ID value objects (UserId, OrderId, etc.), which reduces a whole class of bugs where IDs get swapped between entities or passed to the wrong repository method.
• Roadmap: Doctrine ORM 3 upgrade. Release 1.3.2 specifically improves compatibility with Doctrine ORM ^3 via better EntityValueResolver support. If the roadmap includes an ORM 3 migration, this package is now a lower-risk dependency on that path — worth noting in the upgrade spike.
• Build vs. buy. The alternative is hand-rolling ID value objects plus custom Doctrine types and argument resolvers in-house. That is ~a few hundred lines of glue code with ongoing maintenance, so buying (adopting) is usually the correct call unless ID handling is genuinely core to the product.
• Use cases to prioritize: multi-tenant systems where IDs must be validated/normalized at boundaries; APIs that expose IDs publicly and benefit from consistent parsing/serialization; codebases with many entities where developer error rate on ID plumbing is measurable.
• Not a driver for: user-facing features, performance work, or anything customer-visible. This is an internal correctness/maintainability play.

When to Consider This Package

Adopt when:

• You have (or expect) a meaningful number of entities/models and ID parameters flowing through controllers, services, and repositories.
• You are on Doctrine ORM 2.x or 3.x and want typed IDs to work with Symfony's EntityValueResolver (route-parameter-to-entity conversion). Note 1.3.2 is the release that makes the ORM 3 combination work well — pin at ^1.3.2 if ORM 3 is in play.
• Your team is comfortable with value objects and is willing to accept the small ceremony cost of converting at boundaries (HTTP, queues, persistence).
• You want validation/normalization of IDs in one place rather than repeated inline checks.

Look elsewhere or defer when:

• The application is small or has a handful of models — the overhead likely exceeds the benefit.
• You are Laravel-first with no Doctrine. This package's most valuable integration (EntityValueResolver, Doctrine custom types) is Symfony/Doctrine-centric; in Laravel you'd use it mainly as a plain value-object library with Eloquent casts and route binding, which is workable but gives you less of the packaged value.
• You need ID generation strategy (UUIDv7, ULID, snowflake) as the primary concern — evaluate dedicated UUID/ULID libraries first; this package is about typing and resolving IDs, not generating them.
• Hot paths where an extra object allocation per ID is measurable — validate with a benchmark before adopting broadly.

Release-specific read on 1.3.2: patch-level, additive compatibility fix, no breaking changes, no deprecations. Low urgency; fold into the next routine dependency bump. Its main signal is that the package is actively tracking Doctrine ORM 3, which is a positive maintenance indicator.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-risk open-source dependency that makes entity IDs type-safe in our PHP code. The practical benefit is fewer production bugs caused by mixing up IDs, plus IDs that are validated consistently at the edges of the system. The 1.3.2 release is a maintenance patch that improves compatibility with Doctrine ORM 3 — it unblocks or de-risks our eventual ORM upgrade and confirms the package is actively maintained. Cost is a small amount of integration work and a modest amount of developer ceremony; there is no user-facing change and no licensing or vendor-lock-in exposure.

For engineering:

• Adopt incrementally: introduce typed IDs on new entities and the highest-traffic existing ones first; do not attempt a big-bang refactor.
• Pin ^1.3.2 if you are on Doctrine ORM 3 — earlier versions have weaker EntityValueResolver support in that combination.
• Budget for boundary conversion code: HTTP request mapping, queue payload serialization, and fixtures/factories are where the friction shows up.
• Establish a convention early (naming, fromString/__toString, JSON serialization) so the codebase does not end up with three different patterns.
• Success signal: reduced ID-related defects and fewer "wrong ID passed" incidents in review, not raw velocity.