Eb Plantumlbundle Laravel Package

Technical Evaluation

Architecture fit. The single most important finding for a Laravel-oriented brief: emmanuelballery/eb-plantumlbundle is a Symfony bundle, not a Laravel package. It is built on Symfony's Bundle base class, the DependencyInjection extension/config-tree pattern, and Doctrine's metadata layer. There are no service providers, facades, or Laravel package autodiscovery. It will not work against Eloquent, and it will not see Laravel models, migrations, or schema builders. For a Laravel codebase this is a non-starter as a direct dependency — the honest evaluation is "does the underlying idea map to our stack," not "does this package install."

What it actually does. It introspects Doctrine entity mappings and emits PlantUML source text describing class relationships. It is developer tooling and documentation automation, not a runtime dependency. That materially lowers blast radius: it never sits in the request path, cannot add production latency, and does not touch user data. This is the kind of thing a TPM can sponsor as a low-risk spike rather than as a platform commitment.

Integration feasibility. For a Symfony/Doctrine application, feasibility is high in principle and low in evidence. The package shows zero stars, zero dependents, and a score of 0, with no visible maintenance signal. We have no evidence of compatibility with current Symfony 6.x/7.x, PHP 8.x, or modern Doctrine ORM. It is plausibly built against older Symfony conventions (annotation-era config, older extension wiring) and the deprecated ClassMetadata access patterns. For Laravel specifically, feasibility is zero without a rewrite — the equivalent capability would be a small custom command walking Eloquent's Schema::getColumns() or model reflection into PlantUML.

Technical risk.

• Stack mismatch risk: certain. Highest-severity finding. If the target is Laravel, stop the evaluation.
• Abandonment risk: high. No community, no dependents, no triage signal. If it breaks, we own the fork.
• Version drift risk: high. Unmaintained Symfony bundles age badly across majors, and Doctrine's metadata API has shifted across ORM majors.
• Security risk: low. Dev-only generator, no assumed network surface — but still run composer audit and read the source before installing.
• Output fidelity risk: medium. Diagram completeness depends on clean mappings; attribute-vs-annotation differences can silently drop relations.
• Licensing risk: low but unverified. Confirm the license permits internal fork and modification, because forking is the likely end state.

Key questions.

1. Is the target application actually Laravel/Eloquent, or Symfony/Doctrine? This gates everything downstream.
2. If Symfony: which symfony/*, PHP, and doctrine/orm versions are pinned, and does the package's composer.json admit them?
3. What is the concrete deliverable — a one-off architecture diagram for a review, or a regenerated-in-CI artifact? The answer changes the risk calculus entirely.
4. Are we willing to own a fork, or does the org require a supported dependency with a security-response path?
5. Is there a maintained alternative that fits better — SchemaSpy for DB-first ERDs, Mermaid for Markdown-native diagrams, IDE UML plugins, or a ~1–2 day internal generator?

Integration Approach

Stack fit. Acceptable only for Symfony + Doctrine ORM applications with centralized entity metadata. Not viable for Laravel, and meaningless for any PHP project without Doctrine metadata to harvest. The realistic Laravel translation is conceptual, not literal: the pattern (introspect the model layer, emit diagram text as a build artifact) is worth copying; the package is not.

Migration path. If a Symfony/Doctrine surface exists, treat this as a local developer tool, never an application dependency:

• Add as require-dev on a throwaway branch or standalone sandbox, pinning the version explicitly — no floating constraints.
• Verify install against our locked Symfony/PHP/Doctrine versions before writing any config.
• Inspect DependencyInjection/Configuration.php in vendor/ as the authoritative config reference; READMEs on low-traffic bundles are routinely stale relative to the config tree.
• Once output is validated, choose deliberately: keep as require-dev, vendor it, or extract the generation logic into an internal command and drop the package.

For a Laravel target, skip the migration entirely and scope a small internal Artisan command instead — a day or two of work for basic class/ER diagrams from model metadata, with no ownership liability.

Compatibility. Expect friction at three seams: Symfony bundle registration and legacy extension patterns, the Doctrine ClassMetadata shape across ORM majors, and PHP typing/deprecation errors on 8.x. Output is PlantUML text, which is version-neutral and is the one thing genuinely in its favor. Decide the render path up front: a PlantUML server (no Java dependency, but network egress that many CI runners block) versus local plantuml.jar rendered in a Makefile/CI step (offline and deterministic, slightly more setup).

Sequencing.

1. Confirm stack — Symfony vs. Laravel. Gate; do not proceed past a "Laravel" answer.
2. Time-boxed sandbox install against pinned versions — one day maximum.
3. Generate diagrams for one representative bundle/module and diff against expectations.
4. Half-day comparison against maintained alternatives or a custom generator.
5. Decision memo: adopt as require-dev, fork with a named owner, or build internally. Default answer is decline.

Artifact policy. Generate into var/ and gitignore it, or publish rendered SVG from CI. Committed .puml files rot within a sprint; committed .svg files produce noisy, unreviewable diffs. Wire a Composer script (composer diagrams) that clears cache first — stale Doctrine metadata cache is the single most common cause of "my new entity is missing from the diagram."

Operational Impact

Maintenance. Low operational burden — it is dev-only and never runs in production — but high ownership burden if adopted. With zero maintainers and zero dependents, we become the de facto maintainer by default. Budget for a named fork owner and periodic compatibility checks on every Symfony, PHP, and Doctrine upgrade. If nobody is willing to accept that ownership, that is the decision.

Support. Effectively none. No community, no issue triage, no dependents to lean on. Internal knowledge transfer is the only support path, which means the fork, the generation steps, and the render path all need to live in the repo as documentation, not in someone's head. Practical guidance: treat bin/console list filtered to the bundle's namespace and its --help output as the real documentation, and read the bundle's Command/ directory to understand which services do the scanning and rendering.

Scaling. Not a runtime scaling concern; the risk is codebase scaling. Large entity graphs produce unwieldy diagrams and slow generation, and diagram value degrades quickly past a few dozen entities — a wall of boxes nobody reads. Scope output per-bundle or per-domain, and plan filtered views from the start rather than attempting a whole-application diagram. For a Laravel equivalent, the same constraint applies to model counts across domains.

Failure modes.

• Install-time incompatibility with current Symfony/Doctrine (most likely outcome of the spike).
• Silent degradation: diagrams generate but omit relations due to mapping-style differences — the dangerous case, because it looks like success.
• Doctrine or Symfony major-version upgrade breaks metadata introspection post-adoption, on someone else's schedule.
• "Zombie dependency": sits in require-dev, unmaintained, accumulating audit noise and upgrade friction every cycle.
• One-off diagram generated, committed, and never regenerated — the most likely real-world failure, and an organizational one rather than technical.

Ramp-up. Minimal for anyone fluent in Symfony and PlantUML — a few hours to a first diagram. The genuine ramp-up cost is organizational: establishing who owns the fork, how and when diagrams regenerate, and where output lives (repo docs versus CI artifact). Without those three answers, the tool produces a single diagram that decays into false confidence.

TPM recommendation. Do not adopt as a dependency. Zero stars, zero dependents, a score of 0, a single-maintainer profile, and — decisively — it is a Symfony bundle presented in a Laravel-oriented brief, so it does not fit the stated stack at all. The capability it provides is replicable in one to two days of internal work against whichever ORM we actually run, with no ownership liability and no version-drift exposure. If a Symfony/Doctrine surface exists elsewhere in the estate, fund a ≤2-day spike to read it as a reference implementation only, with "decline" as the pre-agreed default. For the Laravel estate, the right move is a small internal Artisan generator (or a maintained alternative like SchemaSpy for DB-first ERDs or Mermaid for Markdown-native diagrams) — and treat the underlying idea, "documentation as a build artifact," as the thing worth investing in.