Plantuml Bundle Laravel Package

Product Decisions This Supports

• Documentation strategy — the "auto-generate vs. hand-maintain vs. buy" call. This bundle renders UML (primarily structural/class diagrams) from source text inside a Symfony app, giving you a cheap fourth option alongside hand-drawn diagrams and paid modeling tools. The PM-relevant value is that diagrams stop rotting the moment a refactor lands, which is the failure mode that kills most architecture-doc initiatives.
• Technical-debt and architecture-review prioritization. On-demand diagrams give you a fast visual read on coupling, inheritance depth, and module boundaries — concrete inputs when deciding whether a subsystem is worth extending versus replacing, and when sequencing a refactor roadmap.
• Onboarding and knowledge-transfer investment. A generated diagram set shortens ramp-up for new engineers and gives non-engineering stakeholders a system overview without reading source. This supports the "do we fund formal onboarding docs?" decision.
• Contractual and audit deliverables. As an IRSTEA/INRAE research-institute bundle, it fits contexts where architecture documentation is a compliance or client artifact rather than a product feature.
• Prioritizing internal tooling work. Adoption cost is roughly one dependency plus a generation step, so it can be slotted into a maintenance sprint as a low-commitment experiment instead of a roadmap line item.

Caveat to carry into every one of these decisions: this is a Symfony bundle, not a Laravel package. Its convenience layer is Symfony bundle bootstrapping, which Laravel does not have. The real gating question is "do we run Symfony?" — not "is this a good Laravel package?" Second caveat: self-hosted institutional GitLab, no public star history, zero known dependents, score of 0. Treat it as an unproven internal artifact, not a vetted ecosystem dependency.

When to Consider This Package

Adopt or trial it when:

• The codebase is Symfony/PHP and already uses bundles — otherwise the "bundle" convenience evaporates and you are hand-wiring a generator.
• You need structural diagrams derived from source for documentation, audit, or onboarding, and hand-maintained diagrams have already proven unsustainable.
• The team accepts maintenance ownership: no visible community, no dependents, no package-registry presence, French-language docs. Plan for a possible fork.
• You can timebox a spike — one engineer, one sprint, one representative (ideally messy) module — and judge output quality before committing.
• Diagrams are an internal aid or compliance deliverable, not a polished customer-facing artifact with freshness guarantees.

Look elsewhere when:

• You are on Laravel or framework-agnostic PHP. Use standalone PlantUML plus a parser, or a small in-house reflection-based generator, instead of maintaining a Symfony-kernel shim.
• You need sequence/behavioral diagrams or CI-enforced architecture rules (dependency-direction checks). This appears to be a static structural generator; pair with or replace by dedicated architecture-testing tooling.
• You require vendor support, SLAs, or a security-reviewed supply chain — no evidence of any of these.
• Actively maintained dependencies are a hard requirement; a zero-signal repo is a standing upgrade tax.
• The org is polyglot and better served by a hosted diagramming or docs-as-code platform with multi-language support.

How to Pitch It (Stakeholders)

For executives: We can generate up-to-date architecture diagrams straight from our Symfony code at essentially no licensing cost — one dependency and a generation step. That gives us documentation that survives refactors, which helps onboarding, architecture reviews, and any client or audit deliverable requiring design documentation. The honest trade-off: this is an unproven package from a research institute's internal GitLab with no community traction and no dependents, so we should run it as a timeboxed pilot, not a platform commitment. The cost of finding out is one engineer for one sprint.

For engineering: It's a Symfony bundle that emits PlantUML from source. If we're on Symfony, evaluation is cheap and the output tells us quickly whether diagram quality justifies the wiring. Assume we own it from day one — no upstream support, budget for a possible fork. If we're not on Symfony, skip it: evaluate standalone PlantUML plus a parser, or a thin in-house generator. Also flag that generation is a build-time concern, so keep it a CI artifact rather than an application runtime feature. Ask: one volunteer, one sprint, diagrams for our most tangled module, then a go/no-go.