Weave Code
Arch Viewer Laravel Package
open-solid/arch-viewer
Open Solid Arch Viewer is a Laravel package that helps you explore your application's architecture. It visualizes classes, dependencies, and relationships in an interactive diagram, making it easier to understand structure, spot coupling, and navigate large codebases.
Doc generator for your OpenSolid projects
Frequently asked questions about Arch Viewer
- How do I install open-solid/arch-viewer?
- Install it as a dev dependency with composer require --dev open-solid/arch-viewer. Then publish any package configuration and run the provided Artisan command to generate or serve the architecture view. Because it is developer tooling, keep it out of production require and deployment steps. Check the README for exact command names and publish tags.
- Which Laravel and PHP versions does open-solid/arch-viewer support?
- The package is Laravel-focused, but the supported PHP and Laravel ranges should be verified in its composer.json before adoption. Constraint compatibility is the cheapest early gate: if your PHP or Laravel version falls outside the package's require block, stop there. For OpenSolid-based codebases, also confirm the OpenSolid core version constraints.
- What does the Arch Viewer dependency graph show?
- It maps classes, namespaces, and their dependencies so you can see how application, domain, and package code relate. You can drill down from modules to individual classes, which helps spot coupling and navigate unfamiliar areas. It is an architectural exploration tool, not a runtime profiler or a replacement for static analysis.
- Is open-solid/arch-viewer safe to use in production?
- It should not be part of your production runtime at all; install it with require-dev and run it locally or in CI. It has no request-path role and should never be deployed as an application dependency. Treat it as unvetted third-party source until license, maintenance, and code review checks pass.
- How do I configure which folders or namespaces Arch Viewer scans?
- The package provides configurable paths, typically published into a config file, so you can point discovery at app, domain, or package directories. Laravel-aware discovery attempts to find relevant code automatically, but explicit path configuration keeps output focused. Start with one bounded context rather than the whole monolith to validate fidelity.
- Can I run open-solid/arch-viewer in CI?
- Possibly, but confirm the output format and determinism first. If the generated graph or documentation is stable enough to diff, you can use it as a lightweight architecture review artifact in CI. If it relies on runtime container bootstrapping, CI may be fragile; prefer static discovery such as reflection or AST where available.
- Does Arch Viewer use reflection or runtime bootstrapping to discover dependencies?
- The package performs Laravel-aware discovery, but the exact mechanism matters for CI safety. Static discovery via reflection or AST is generally safer and more predictable than booting the full application container. Validate this against your codebase, especially for handlers registered through custom service providers or attributes.
- Is open-solid/arch-viewer actively maintained and what license is it under?
- That must be confirmed before adoption: check the repository's license file, last commit date, open issues, and release cadence. Low community signals, such as few stars or no dependents, mean limited external scrutiny. If the license is unclear or the repo is dormant, treat it as a fork candidate rather than an adopted dependency.
- Can I limit the architecture view to a single module or bounded context?
- Scoping depends on the package's configuration and whether discovery is all-or-nothing. Configure paths to one module or bounded context if supported, because that is the best way to compare generated output with a hand-written architecture summary. If scoping is not supported, the tool may produce a noisy whole-application graph.
- What are the alternatives if open-solid/arch-viewer doesn't fit?
- Fallbacks include Deptrac for dependency rules, static analysis plus a small in-house reflection script, or manually maintained architecture docs. A short custom script over reflection plus a static docs page is often enough for a narrow, well-understood domain. Decide between adopting as require-dev, forking, or building the in-house equivalent before the spike ends.
Weaver
How can I help you explore Laravel packages today?