- Can I use onurb/doctrine-yuml-bundle in a Laravel application?
- It is a Symfony bundle, not a Laravel package, so there is no service provider or Laravel-native configuration. It only fits a Laravel app that has deliberately adopted Doctrine ORM (for example via laravel-doctrine/orm) instead of Eloquent, because it introspects Doctrine ClassMetadata rather than Eloquent models. On a standard Eloquent codebase it offers nothing out of the box, and you should not introduce Doctrine just to get diagrams.
- How do I install and register the bundle?
- Install it with composer require --dev onurb/doctrine-yuml-bundle so it never reaches production images. Then register the bundle in config/bundles.php, gated behind a dev or test environment check, and point it at your entity directories before invoking its console command. Because it is dev-only tooling, keeping it out of the production dependency graph is the main installation concern.
- Does it support Symfony 6/7 and PHP 8.2 or newer?
- Assume a fork is required. This is a low-star, single-maintainer bundle of Symfony 3/4 and PHP 7.x vintage, and Doctrine's shift from annotations to PHP 8 attributes often breaks annotation-era metadata parsing such as getAnnotationReader() paths. Check the actual composer.json constraints and attribute handling against your target Symfony and PHP matrix before writing any integration code.
- Does it render diagrams locally or does it call a third-party service?
- It emits yUML syntax, typically as a yuml.me URL, which means rendering happens through that external service rather than locally. The yuml.me dependency is the sharpest operational edge given availability and longevity concerns. If you need reliability, self-host a renderer or replace the emitter with Mermaid or PlantUML and commit the generated source file.
- What happens with large domain models?
- yUML URLs are length-bounded, so a big entity graph will silently truncate or fail to render instead of producing a clear error. Validate output fidelity against your largest bounded context before trusting it. For substantial models a file-based emitter such as Mermaid or PlantUML is the safer choice.
- Is it safe to run in production?
- Yes, in the sense that it is dev-only tooling and never touches production traffic, so the risk is not runtime incidents. Keep it in require-dev and gate bundle registration to dev and test environments anyway. The real risks are upstream maintenance and the external rendering service.
- Is the bundle actively maintained, and what is the bus factor?
- Expect effectively one maintainer, roughly 41 stars, and near-zero downstream dependents, so bus factor is one and upstream is close to unmaintained. If you adopt it, budget for a fork you own: dependency bumps, PHP and Symfony upgrades, and Doctrine API changes all land on your team. Because it is dev-only, that cost is opportunity cost rather than incident cost.
- Does it handle OneToMany, ManyToMany, inheritance, and embeddables correctly?
- That coverage is not something you should assume from the README of a bundle this small and this old. Validate metadata extraction against your real entity set, including association types, inheritance hierarchies, and embeddables, before relying on the output. This verification is exactly why the work should start as a throwaway-branch spike.
- What are the alternatives if I want Doctrine diagrams without this bundle?
- Mermaid, PlantUML, and SchemaSpy-based tooling all cover the same ground and integrate cleanly into an existing docs pipeline. The core logic here, walking metadata and emitting graph text, is roughly 100 to 200 lines, so an in-house console command emitting Mermaid or PlantUML is often cheaper over a 12-month horizon than adopting and maintaining this bundle. Compare equivalent output before committing.
- How should I wire it into CI, and how much effort should I plan for?
- Treat it as a 1 to 2 day spike rather than a dependency commitment: prove metadata extraction on a throwaway branch, assess output fidelity, then make an explicit adopt, fork, or build decision. Once adopted, generate the diagram as a build artifact or a make docs target instead of an ad-hoc developer action, so the diagram stays current. Commit the generated source file and render it through your existing documentation pipeline rather than relying on an external URL at read time.