Doctrine Json Bundle Laravel Package

Product Decisions This Supports

• JSON column storage on legacy stacks: If the product runs on an older Symfony/Doctrine combination that predates the native json DBAL type, this bundle can unblock storing semi-structured payloads (tenant config, feature flags, audit metadata, third-party webhook bodies) without a schema migration per new field.
• Schema flexibility vs. relational rigor trade-off: Supports the roadmap decision to ship "custom fields" or "user-defined attributes" before committing to a full EAV model or a dedicated document store — a classic build-vs-buy inflection point.
• Build vs. buy signal — negative: With 1 star and 0 dependents, this is effectively a "build a 40-line custom DBAL type ourselves" decision disguised as a dependency. The PM takeaway is insourcing the capability, not adopting the package.
• Roadmap sequencing: If JSON columns are on the near-term roadmap, the decision this informs is whether to (a) upgrade Doctrine to a version with native JSON support, (b) write an internal type, or (c) adopt a package — and this package only wins under (c), which is the weakest option here.
• Use cases it nominally covers: flexible product catalogs, per-tenant settings, event/telemetry blobs, i18n payloads, and API response caching. All of these are better served by native JSON/JSONB types plus query-side functions.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is pinned to a legacy Symfony + Doctrine DBAL version lacking a native json column type, and a framework upgrade is off the table for this cycle.
• You need JSON persistence quickly for a low-blast-radius, internal, or non-critical-path feature.
• You are willing to vendor the code into your repository (fork it) rather than depend on the upstream, given the maintenance signal.
• Your team has reviewed the source and confirmed it covers only what you need — no hidden coupling to specific ORM versions.

Look elsewhere (or build in-house) when:

• You are on modern Doctrine DBAL / Symfony, where native JSON types make this redundant.
• You need querying into JSON (JSONPath, ->> operators, index-backed containment). This bundle is a persistence shim, not a query layer; you'll want native JSONB on PostgreSQL, MySQL generated columns, or a document store.
• Any production SLA is involved — 1 star, 0 dependents, and a single maintainer is an unacceptable supply-chain and bus-factor risk for customer-facing data paths.
• You need typed, validated, or schema-evolved JSON. Prefer a DTO/serializer approach or a JSON-schema validation layer over raw column passthrough.

How to Pitch It (Stakeholders)

To executives: A community package was evaluated for adding flexible JSON data storage. Recommendation: do not adopt it as a dependency. It has negligible adoption (1 star, no downstream users), which means unmaintained code sitting in our critical data path — a compliance, security-patching, and continuity risk disproportionate to the small amount of functionality it provides. The underlying need is real and on the roadmap; the right answer is either a Doctrine upgrade (native JSON support, zero new dependencies) or roughly a day of internal engineering to replicate the capability with code we own and can audit.

To engineering: Treat this as a capability reference, not a dependency. The bundle's scope — a custom Doctrine DBAL type for JSON columns, with mapping and serialization — is small enough to implement internally in a few dozen lines and test properly, and doing so removes an unowned third-party from our upgrade path. If there is a hard deadline and a legacy Doctrine version blocking native JSON, fork the code into an internal namespace as a clearly-labeled stopgap, isolate it behind a repository/service boundary, and log a follow-up to delete it once the Doctrine upgrade lands. Do not let it leak into domain entities directly.

Bottom line: The need is legitimate; this specific package is not the answer for anything but a short-lived legacy workaround.