Doctrine Diagram Bundle Laravel Package

Product Decisions This Supports

• Framework fit is the first decision. Despite the "Laravel/PHP" framing, this is a Symfony Bundle built on Doctrine ORM metadata. It does not work with Laravel's Eloquent. The real decision it informs is "do we standardize on Doctrine for this service, and if so, what do we get for free?" — treat it as a Symfony-stack line item, not a general PHP one. v2.0.0 sharpens this: it now requires PHP 8.2+ and drops Symfony 6, so it only serves services already on (or committed to) Symfony 7.
• Runtime/platform floor as a gating decision. v2.0.0 makes the package a forcing function for your PHP upgrade. Adopting it means coupling diagram generation to ≥8.2; staying on 8.1/Symfony 6 means pinning ^1.2 and accepting a frozen feature line. This is a real roadmap input if a platform upgrade is already on the table.
• Build vs. buy for schema documentation. Auto-generated ERDs from entity metadata replace a recurring manual chore (redrawing diagrams in dbdiagram/DrawSQL/DataGrip) or a paid SaaS seat. The trade is losing interactive/collaborative editing for zero marginal cost and zero drift.
• Documentation-as-code roadmap. Because the diagram is derived from the same annotations the ORM already reads, it can run in CI and be published as a build artifact. This supports a decision to make architecture docs generated rather than maintained, which is a durable process win beyond this one package.
• Scoped diagrams become a first-class option. The new include filters (alongside the reworked exclude filters) let you generate a diagram per module/bounded context rather than one monolithic wall of entities. That upgrades the "multi-service repos get their own diagram" use case from a repo-splitting trick to a supported, single-command workflow — worth weighing when deciding how to document a modular monolith.
• Onboarding and review tooling. A current ERD shortens ramp-up for new engineers and gives reviewers a shared picture during migrations or schema-heavy PRs. It informs whether to invest in a "schema visibility" workstream at all.

When to Consider This Package

Adopt when all of these hold:

• The service is Symfony 7+ with Doctrine ORM as the source of truth for schema, running PHP 8.2 or newer.
• You want ERDs in docs or CI and are willing to accept the package's rendering backend (Graphviz/PlantUML) as a build dependency.
• You need subset or per-module diagrams — the new --include filters make this a genuine reason to pick v2 over v1, and over manual tooling.
• The team is small enough that a low-traffic, single-maintainer package is an acceptable dependency — this sits at ~83 stars and 0 dependents, so you are effectively an early adopter. A 1.x → 2.x major bump is a sign of active maintenance, not of ecosystem validation; both statements remain true.
• Your schema is not sensitive to expose as a generated artifact (table/column names in CI logs and published docs).

Look elsewhere when:

• Laravel/Eloquent. Wrong tool entirely; you'd need a schema-introspection approach (doctrine/dbal against a live DB, or a dedicated Laravel ERD tool) instead.
• You're still on PHP 8.1 or Symfony 6. v2 is not for you; v1.2.x is the ceiling and will not receive the filter improvements.
• You need interactive, collaborative, or hosted diagramming — buy dbdiagram/DrawSQL/ERD tooling and accept the maintenance cost.
• You need fine-grained control over layout, styling, or non-Doctrine schema objects (raw SQL views, triggers). Include/exclude filters control which entities appear, not how they're rendered or whether unmapped DB objects show up — you'll still fight the generator.
• Dependency-risk tolerance is low. No dependents means no ecosystem validation; if your org requires a maintenance/security posture review for every new dependency, the cost of clearing this one may exceed the value of generated diagrams. Mitigate by pinning the version and confirming the surface is small enough to fork.
• You need diagrams of the live database rather than the mapped model — those can diverge, and this tool only sees the entities.

How to Pitch It (Stakeholders)

For executives: A free, MIT-licensed utility that turns our Symfony/Doctrine data model into up-to-date ER diagrams automatically. It removes a recurring manual documentation cost and reduces the risk of decisions being made against stale schema pictures. Cost is near zero; the main considerations are that it's a small, single-maintainer open-source project and that v2 requires PHP 8.2+ and Symfony 7, so it rides along with our platform upgrade rather than leading it. We pin the version and keep the integration thin enough to replace.

For engineering: One command (wired into CI) produces ERDs straight from entity metadata — no separate diagram source to keep in sync with the code. v2.0.0 is a breaking major: PHP 8.2 minimum, Symfony 6 dropped, --exclude now takes repeated flags instead of a comma-separated list, and --include filters are new (useful for per-module diagrams). Migration is a CLI-argument edit plus a platform check — small, but it will silently change behaviour in existing CI scripts if we don't touch them. Still a Symfony bundle over Doctrine, so it's a non-starter for our Laravel services and won't see raw SQL objects. Treat it as a documentation build step, not a runtime dependency, and expect to own minor fixes if upstream goes quiet.