- Is irstea/plantuml-bundle a Laravel package?
- No. It is a Symfony bundle hosted on an institutional GitLab, built around Symfony bundle registration, the DI container, and Symfony configuration conventions. Laravel has no bundle loader, so the package does not participate in package discovery or register a service provider. Treat it as reference material or a standalone generator, not a Laravel dependency.
- Can I install irstea/plantuml-bundle with Composer in a Laravel app?
- Not through normal Packagist resolution. The source lives on gitlab.irstea.fr rather than Packagist or GitHub, so composer require fails unless you add a VCS repository entry, and access may require IRSTEA credentials. Even after installation, nothing boots under Laravel because there is no bundle kernel. Verify repository visibility and license before spending time on this.
- Does the bundle support Laravel package auto-discovery?
- No. Laravel auto-discovery looks for a service provider in composer.json extra.laravel, and this package exposes Symfony bundle metadata instead. You would have to hand-write a service provider and shim Symfony container lookups into Laravel's container. That means maintaining a permanent compatibility layer for a developer-tooling feature.
- What does irstea/plantuml-bundle actually do?
- It integrates PlantUML into a Symfony application so you can generate UML and other diagrams from PlantUML text definitions. It provides a Twig extension for embedding diagrams in templates, plus services and configuration for pointing at either a PlantUML server or a local executable. It is aimed at UML, sequence, class, and architecture diagrams.
- What runtime dependencies does PlantUML need?
- PlantUML itself is a Java application, so any environment that renders diagrams needs a JRE present. Many diagram types, including class and architecture diagrams, also require Graphviz. That adds image-size and CI complexity, so plan for a container that includes both.
- How can a Laravel team use this package without adopting Symfony wiring?
- The lowest-risk path is a CI-only sidecar: clone the repo into a build stage, run it as a standalone generator, emit .puml files, and publish them as artifacts. Keep it out of composer.json so the blast radius stays contained. If the output proves valuable, vendor the generation classes into app/Support/Uml and replace Symfony service lookups with Laravel container calls.
- Is the license clear enough for commercial use?
- No license is visible in the repository metadata, and institutional GitLab projects often carry internal-only terms. That could block commercial use, forking, or redistribution. Confirm the license in writing before you depend on it, and do not assume an open-source license just because the source is readable.
- Does it generate diagrams from PHP source code or only from .puml text?
- The description says it generates diagrams from PlantUML text definitions you supply. It does not clearly state whether it parses PHP source or Symfony bundle metadata to auto-generate diagrams. This matters because auto-generation from bundle metadata would produce a diagram of the wrong architecture in a Laravel app. Ask the maintainers directly.
- What PHP and Symfony versions are supported, and is it maintained?
- No release tags, version constraints, or support range are visible, and the project shows no stars or dependents. Maintenance cadence is unknown, and the bus factor is effectively one research institute team. Check the last commit date and PHP range before assuming compatibility with PHP 8.2 or 8.3.
- What are the alternatives for generating PlantUML diagrams in Laravel?
- You can call the PlantUML jar directly from an Artisan command or a CI job, which avoids the Symfony coupling entirely. For architecture documentation, borrow the reflection or AST-driven emission approach rather than the bundle wiring. If you need a maintained package, look for a Laravel-specific wrapper or write a thin one yourself.