Doctrine Generic Types Laravel Package

Product Decisions This Supports

• Build vs. buy for a custom DBAL type layer. The package is essentially a small piece of infrastructure: base classes that let a Doctrine DBAL type delegate conversion to an underlying type instead of reimplementing convertToDatabaseValue / convertToPHPValue for every column. The real decision it informs is "do we standardize a type layer, or keep writing one-off Type subclasses?" — and the answer depends on whether you expect to accumulate more than two or three of them.
• Whether to standardize persistence of value objects. If the roadmap includes encrypted columns, money/currency objects, strongly-typed enums, JSON-backed collections, or geography values, each becomes a custom Doctrine type. Generic/reusable types are the mechanism that keeps that list from becoming N nearly-identical classes with copy-pasted conversion logic.
• Doctrine adoption itself in a Laravel codebase. This package only exists on the "we use Doctrine ORM/DBAL inside Laravel" branch. Its usefulness is a downstream consequence of that architectural decision, and should be evaluated as a footnote to it, not as an independent adoption.
• Framework-agnostic vs. framework-native persistence. Relevant to a decision to keep the domain layer portable (Doctrine annotations/attributes, no Eloquent coupling) versus committing to Eloquent. If portability is a stated goal, small DBAL extensions like this buy real optionality; if not, they are dead weight.
• Dependency-risk budgeting (this is the dominant decision). With 0 stars, 0 dependents, and a single-vendor maintainer, the decision this package actually forces is not "should we use it" but "do we vendor/fork a ~MIT-licensed reference implementation, or write 60 lines ourselves?" Both are defensible; adding it as a live Composer dependency on a critical path is the option that needs justification.
• Roadmap signal, not roadmap input. Treat it as evidence that composable Doctrine types are a recognized gap, useful when scoping an internal shared-persistence package. It is not a component to schedule work around.

When to Consider This Package

Adopt (or, more likely, vendor) when all of the following hold:

• You already run Doctrine DBAL/ORM in a Laravel application (e.g., via laravel-doctrine) and are not migrating to Eloquent.
• You have, or credibly expect, 3+ custom types whose conversion logic is "call the inner type, then transform" — encryption, hashing, JSON wrapping, unit-aware scalars, enum-like value objects.
• You are comfortable reading the source as the documentation; there is no meaningful doc site, no support channel, and no community to ask.
• You can pin an exact version or copy the classes into your own namespace, and you have a Doctrine DBAL version constraint you can actually satisfy — verify compatibility explicitly, since Doctrine's Type API has shifted across 2.x → 3.x → 4.x and a package with no dependents has no compatibility pressure from users.
• The blast radius is small: a wrong mapping fails loudly in tests, not silently in production data.

Look elsewhere — or skip entirely — when:

• You are Eloquent-first. No Doctrine, no problem; this package has nothing to offer.
• You need exactly one custom type. Write it yourself; the abstraction pays for itself only at volume.
• You require maintained dependencies. No stars, no dependents, no issue traffic means no security-response path and no upgrade guarantee. If your org has a dependency-approval gate with maintenance criteria, this fails it by definition.
• You need behavioral guarantees around NULL, empty strings, or driver-specific coercion. Generic-type delegation tends to inherit the inner type's edge cases; validate against your actual columns before trusting it.
• You are on the newest Doctrine major. Assume incompatibility until proven otherwise; the cost of proof may exceed the cost of reimplementation.

How to Pitch It (Stakeholders)

To executives: This is a ~MIT-licensed micro-library that removes duplication when a Doctrine-based application needs several custom database column types. The strategic read is low value, low risk, but also low signal — zero stars and zero dependents mean it is effectively a private utility someone published, not an ecosystem component. Recommendation: do not add it as a production dependency; if the team wants the pattern, copy the relevant classes into our own codebase (an afternoon of work) and own them. Cost of the "buy" path is trivial either way; cost of the "depend" path is an unmaintained transitive dependency we can't get support for. The decision to flag upward is not this package — it's whether the Doctrine-in-Laravel bet is still the plan, because this package's entire value is contingent on it.

To engineering: The idea is sound and the surface area is tiny: composable DBAL types that delegate to an inner type so we stop hand-rolling convertToDatabaseValue for every encrypted/JSON/value-object column. The implementation is unproven — no users, no release cadence, no Doctrine-version guarantees. Proposal: vendor the pattern, pin Doctrine DBAL compatibility with a test matrix covering our real column types (NULL handling and driver coercion are where these abstractions break), and keep our own type registry so the mapping stays visible in code review. If after two sprints the vendored copy is doing real work, it was worth the afternoon; if not, we learned the abstraction wasn't needed before we took on a dependency.