Doctrine Yuml Bundle Laravel Package

Getting Started

What it actually does: this is a Symfony bundle that walks Doctrine's ORM metadata and emits yUML class-diagram DSL ([Customer]++1->*[Order], [Foo]^-[Bar], etc.). You then either paste that into yuml.me or hand it the URL the bundle builds for you. It is not a diagrammer itself — it is a metadata-to-DSL translator plus a thin console wrapper.

Install (Symfony app):

composer require --dev onurb/doctrine-yuml-bundle

Register the bundle in config/bundles.php (it is a dev/debug tool, so keep it in require-dev and only enable it in dev/test):

Onurb\DoctrineYumlBundle\DoctrineYumlBundle::class => ['dev' => true],

First use case — "what does my mapping actually look like?" Run the console command the bundle registers and eyeball the DSL before you trust an ER diagram from a third-party tool:

php bin/console list doctrine          # confirm the exact command name first
php bin/console doctrine:yuml:dump     # prints yuml DSL for all mapped entities

If the command name differs in your version (namespacing has changed across releases), list is the fastest way to find it — do not assume.

Where to look first in the source:

1. src/Command/ — the console entry point; tells you every flag (--bundle, --output, filters, etc.).
2. src/DependencyInjection/Configuration.php — the truth about config keys; READMEs on low-star bundles drift.
3. The service that converts ClassMetadata → yUML — this is the piece worth reusing if you want to embed diagrams in docs or CI artifacts.

Laravel note: this is a Symfony Console/Kernel-coupled bundle. In a Laravel app using the full Doctrine ORM, you will not get the command for free. Either run it from a Symfony sidecar, or extract the metadata-to-DSL service and call it from an artisan command you write yourself. Do not expect a ServiceProvider to exist.

Implementation Patterns

1. Snapshot diagrams into version control / docs. The highest-value use is not live rendering — it is committing a generated .yuml file next to your entities so PRs show mapping drift:

php bin/console doctrine:yuml:dump --output=docs/er.yuml

Then a pre-commit hook or CI step diffs docs/er.yuml; a change is a signal that association mapping moved.

2. Filter to the slice you care about. Large apps produce an unreadable wall of classes. Use the bundle's filtering flags (typically by bundle or namespace — confirm flags in the Command class) to dump one bounded context at a time:

php bin/console doctrine:yuml:dump --bundle=SalesBundle > build/sales.yuml

3. Render via URL, not via the site. yUML accepts a diagram encoded in the path, e.g. https://yuml.me/diagram/scruffy/class/<url-encoded-dsl>. If the bundle exposes a URL-echo flag, capture that into your README; otherwise build the URL yourself from the DSL file. Keeping the DSL as the source of truth (and the image as a throwaway) means the diagram survives yuml.me outages.

4. Multi-entity-manager apps. Doctrine metadata is per-EntityManagerInterface. If you run multiple EMs (common with legacy + new contexts), dump each separately and keep separate DSL files; merging them into one diagram produces misleading cross-context arrows.

5. Pair with doctrine:mapping:info and doctrine:schema:validate. yuml shows you the shape; mapping:info shows owning/inverse sides and schema:validate shows whether the shape matches the actual DB. Run all three in a "mapping health" CI job; the yuml diff is the human-readable artifact.

6. Twig / docs integration. If the bundle registers a Twig extension or a service, inject it into an admin controller to render a live diagram on an internal "architecture" page. Treat this as read-only dev tooling — never expose it in production routes.

Gotchas and Tips

• The dependency is dead-ish. 41 stars, 0 dependents. Pin the version in composer.json, and expect PHP/Doctrine version ceilings. If Composer refuses on PHP 8.3, do not fight it — copy the metadata-to-DSL service into your own codebase; it is a small amount of string building and you own the bugs.
• yuml.me availability is the real SPOF. The rendering service has had outages and rate limits. Always persist the .yuml DSL and generate images as a separate, skippable CI step. Never put a yuml.me image URL in a README as the only diagram — it will 404 eventually.
• Associations require both sides to be mapped. If a relation is defined only on the owning side in Doctrine metadata (no inversedBy), the DSL may render an arrow but you will lose the cardinality inference. Mismatched mappings produce correct-looking but wrong diagrams. doctrine:schema:validate is your gut check.
• Flattened inheritance hides the interesting part. Joined/single-table inheritance tends to collapse into repeated attributes. If you rely on the diagram to reason about hierarchy, filter down to the entity subtree and read the Doctrine mapping docs alongside it.
• No --format=svg — it emits text. Do not expect binary output. If you want SVG in CI, pipe the DSL through yuml.me (or a local PlantUML/Mermaid conversion you write) yourself.
• Config keys differ across minor versions. Read vendor/onurb/doctrine-yuml-bundle/src/DependencyInjection/Configuration.php rather than the README. Old blog posts reference keys that no longer exist.
• Only enable it in dev/test. If a production config/bundles.php has DoctrineYumlBundle::class => ['all' => true], you are shipping a command that can enumerate every entity in your domain — trivial info leak, and it is easy to do accidentally with copy-pasted bundle registration.
• Extension point to exploit: the DSL-building service. Bind it to an interface you own in a thin adapter, so if the bundle breaks on the next Doctrine upgrade you swap the implementation without touching your commands or CI. This is the single move that de-risks a low-maintenance dependency like this one.