Doctrine Diagram Bundle Laravel Package

Technical Evaluation

v2.0.0 delta. The core architectural verdict is unchanged — this is still a Symfony bundle and still not installable as-is into Laravel — but the release moves three things that matter to a TPM: the platform floor (PHP 8.2, Symfony 7 only), a CLI contract change (--exclude becomes a repeatable flag), and one genuinely useful capability (--include filters). The release notes are the only new evidence available; the prior assessment's data payload was empty, so confidence in the vendor-health picture is still inferred rather than measured.

Architecture fit. The package is a Symfony bundle, not a Laravel package — this remains the single most important fact. A Symfony bundle is a Kernel-level construct: a *Bundle class, a DI Extension that loads service definitions, optional CompilerPass implementations, and console commands registered through Symfony's container. Laravel has no bundle concept, no bundles.php, and does not boot symfony/framework-bundle, which this bundle's wiring implicitly assumes. Composer autoloading will succeed; the service graph will not assemble. There is still no Laravel package discovery (extra.laravel.providers). v2.0.0 dropping Symfony 6 in favour of Symfony ≥7 does not create a Laravel bridge — it just narrows which Symfony sidecar you could build. Practical conclusion: the bundle itself is not integrable as-is; consume the functionality through the underlying jawira/doctrine-diagram library, wrapped in an Artisan command. The evaluation remains "build a thin internal adapter," not "install a package."

Integration feasibility. Still gated on Doctrine being present. Qualifying teams are narrow: legacy Symfony→Laravel migrations, DDD codebases with a Doctrine domain layer, or apps with a Doctrine read model alongside Eloquent. The 2.0.0 requirements tighten the gate further: PHP ≥ 8.2 and Symfony ≥ 7. Since Laravel 11 requires PHP 8.2 and ships Symfony 7 components, the new floor is clean for Laravel 11/12 shops and excludes Laravel 10 on PHP 8.1 — the same apps that would most likely be mid-Doctrine-migration. Worth flagging explicitly: a dev-only tool that forces an app-wide PHP minor upgrade is no longer a zero-friction dev dependency.

Technical risk.

Key questions for the maintainer/team.

1. Does jawira/doctrine-diagram (the non-bundle library) ship on contracts v2 at the same time, and are the two packages version-locked? The adapter path depends on the library, so a bundle-only v2 release would strand us.
2. Is there a stated support policy — e.g. "current Symfony major only" — or is the Symfony 6 drop a one-off? This determines whether the CI sidecar is a one-off build or an annual upgrade chore.
3. Do --include and --exclude compose, and is filtering applied at the entity level only or also to associations/embed dables that cross a boundary? Cross-boundary edges are exactly where per-module diagrams lose fidelity.
4. Which Doctrine ORM/DBAL majors are in the 2.0.0 tested matrix, and is the metadata API usage ORM-3-ready?
5. Which output formats are supported (PlantUML, Graphviz/DOT, Mermaid, SVG/PNG), and which require external binaries or a JVM in CI?
6. Can it operate in schema-introspection mode against a live database? Not addressed by this release; still the single change that would widen applicability most.
7. Behaviour on large schemas — 200+ entities, nested embeddables, multiple entity managers — now that scoping is available.

Integration Approach

Stack fit. Re-score against the 2.0.0 constraints:

Migration path. Unchanged in ordering, with version notes:

1. Adapter over the underlying library (recommended). Require jawira/doctrine-diagram (contracts v2 line) as require-dev, resolve EntityManagerInterface from the container, expose php artisan schema:diagram with --format, --output, --include, --exclude. Two changes from the prior plan: mirror the new repeatable-flag semantics rather than comma-separated values so the command surface stays aligned with upstream docs, and treat --include as the primary interface — per-bounded-context diagrams are now first-class rather than a post-processing chore. Estimated 1–3 engineer-days, slightly less if include/exclude covers filtering you were going to write yourself.
2. CI sidecar running the bundle's own command. Still zero application coupling, but this option carries the upgrade cost. The --exclude change means any existing pipeline invocation using comma-separated values will silently pass a bogus pattern or error, and Symfony 6 → 7 means the sidecar app itself must be upgraded. Acceptable only if you own the sidecar as a real (small) service.
3. Fork and strip. Now a worse trade: 2.0.0 moved the command surface and contracts, so a fork immediately owes a rebase and inherits a moving target. Justified only for behaviour unreachable from the library.
4. Do not adopt. Still correct for Eloquent-only teams, and now also for PHP 8.1 shops that cannot move.

Compatibility checks before committing.

• Assert php >= 8.2 in the app or in the isolated dev/CI image; do not use --ignore-platform-reqs to sneak a dev dependency past the platform check — you will get runtime surprises in the adapter.
• Confirm the jawira/doctrine-diagram version you install is on contracts v2; a v1 library plus a v2 bundle in any shared tree is an immediate Composer conflict, and it is easy to hit when both are pulled transitively.
• Verify the bundle's doctrine/orm constraint against your installed ORM major, and its symfony/* constraints against the components Laravel 11+ already pins (console, http-foundation, finder, process). The Symfony 7 requirement now aligns with Laravel 11+, which reduces component-conflict risk versus v1 — a real, if minor, upside.
• Still do not let symfony/framework-bundle into the application's root composer.json; confine it to a CI image or sidecar package.

Sequencing.

1. Spike (½ day): scratch branch, load metadata for 5 representative entities, render one diagram on PHP 8.2 with binaries present.
2. Contracts/version check (1 hour, new): confirm library v2 + contracts v2 resolve cleanly alongside laravel-doctrine/orm and your ORM major.
3. Coverage proof + scoping test (1–1½ days): run against the full schema; diff entity/association counts against the mapping. Then repeat with --include per module and verify cross-boundary associations are not dropped. This is the go/no-go gate.
4. Command + config (1 day): Artisan command with repeatable --include/--exclude, plus a config file mapping modules to output paths — this replaces the hand-maintained exclusion lists the old version implied.
5. CI wiring (½ day): artifact upload on schema-touching PRs; Graphviz/PlantUML baked into the image.
6. Documentation and handover, including the pinned version and the upgrade-tracking note.

Operational Impact

Maintenance. Still a dev-only, low-blast-radius dependency — nothing enters the production image. But 2.0.0 changes the maintenance story in two directions. Positively: an active maintainer releasing a coherent major with docs is a materially better signal than the prior "83 stars, 0 dependents, possibly dormant" reading. Negatively: the release demonstrates a current-major-only policy (Symfony 6 dropped outright) and a willingness to raise the PHP floor in a major. Concretely, plan for a breaking upgrade roughly on the Symfony major cadence — annually — and for your adapter to be re-verified each time. If you take path 2 (sidecar), that cadence is now a scheduled obligation rather than a hypothetical. Budget for owning the adapter; the fork scenario is less likely to be forced on you than it was, which is the main operational gain here.

Support. MIT, no commercial backing, no SLA, community triage. The v2.0.0 documentation update is a genuine improvement in self-service support quality — worth reading before writing the adapter, since the CLI semantics you should mirror are now documented. Internal knowledge remains concentrated in the adapter author; keep the pairing recommendation.

Scaling. Scaling dimensions are schema size and render cost, not request volume. --include is a direct, low-cost mitigation for the hairball problem: generate per-module/bounded-context diagrams instead of one monolith, which is also better documentation. Verify boundary handling rather than assuming it. External binaries (Graphviz dot, PlantUML + JVM) remain the likeliest CI friction — pin them in a custom image. Note that the new PHP 8.2 floor applies to that image too.

Failure modes to design against.

Ramp-up. Low to consume, moderate to own. Reading a generated ERD is trivial; regenerating is one command. Writing the adapter requires Doctrine ClassMetadataFactory and association-mapping fluency — about a day for a senior PHP engineer, longer for an Eloquent-only background. v2.0.0 adds a small amount of reading (the new include/exclude semantics) and removes some design work (you no longer need to invent module filtering). Have the adapter author pair during the spike so the knowledge is not single-threaded.

Verdict. Low strategic value, low operational risk, narrow applicability — unchanged in substance. v2.0.0 improves the filtering story and the maintenance signal while tightening the platform gate; net effect on the recommendation is neutral-to-slightly-positive for teams already on Laravel 11+ with Doctrine, and negative for PHP 8.1 / Laravel 10 shops, which should stay on 1.2.0 or decline. The recommendation stands: take the adapter path, pin to v2 and to the matching contracts-v2 library, budget three engineer-days, and treat the Symfony-major cadence as a known annual cost. For Eloquent-centric stacks, the architectural mismatch is still not worth bridging for a diagram generator — and the 2.0.0 release does nothing to change that.