Weave Code
Version Information Bundle Laravel Package
leaseweb/version-information-bundle
A Symfony bundle that gathers and exposes version information for your application and its Composer dependencies, making it easy to surface build/version metadata for monitoring, health checks, and deployment diagnostics.
Leaseweb Version Information Bundle is a lightweight Symfony bundle for exposing application version details through a configurable endpoint. It helps teams verify deployed builds, support debugging, and provide version metadata to monitoring and operations tooling.
- Symfony integration with simple bundle registration
- Configurable endpoint for retrieving version information
- Deployment visibility for build and release verification
- Operational diagnostics for support and health checks
- Minimal setup with a lightweight footprint
Frequently asked questions about Version Information Bundle
- Can I install leaseweb/version-information-bundle in a Laravel application?
- No. It is a Symfony bundle that registers itself in the Symfony kernel and attaches a data collector to symfony/web-profiler-bundle, and Laravel has no bundle concept, no Web Debug Toolbar, and no compatible collector contract. A Composer install into a Laravel 10 or 11 app would either fail on platform constraints or drag in an obsolete Symfony 2/3 dependency tree. Treat it as a reference implementation to read, not a dependency to add.
- What does Leaseweb VersionInformationBundle actually do?
- It shells out to git status and svn status in your project directory, parses the output, and renders branch name, remote URL, changed files, and commit metadata into the Symfony Web Debug Toolbar. Everything is wired through Symfony's DI container and toolbar tag system, so output only appears in the dev environment where the profiler is active. The transferable asset is the idea of surfacing VCS state in a debug panel; the code itself is a few hundred lines of Symfony-specific glue.
- Is this package maintained, and is it safe to depend on in production?
- The repository is effectively abandoned or archived, with no security patching, no PHP 8 compatibility work, and no response to CVEs in its transitive Symfony dependencies. It has roughly 25 stars and zero dependents, so there is no downstream battle-testing or issue history to mine for failure modes. Adopting it means a permanent fork commitment if you ever need fixes, which is why it should be classified as read-the-source, reimplement-the-behavior rather than add-to-composer.json.
- Does it support PHP 8 or modern Symfony versions?
- Unlikely. The bundle targets Symfony 2 with an old constraint set, so modern PHP 8.1+ applications should expect deprecation notices and dependency conflicts, and running composer update against it is effectively unsupported. If a team insists on evaluating it, pin it in a throwaway Symfony sandbox and never in a Laravel composer.json. There is no PHP 8 compatibility work anywhere in the repository.
- What is the Laravel equivalent of showing git status in a debug panel?
- The first-class Laravel pattern is a custom Laravel Debugbar collector (barryvdh/laravel-debugbar) whose collect() method runs git status --porcelain and git rev-parse --abbrev-ref HEAD and returns a compact widget. If Debugbar is not already a dependency, a standalone artisan vcs:status command or a Blade partial in a dev-only layout is cheaper still. Both avoid the Symfony bundle's tag-based collector registration, which has no Laravel analogue.
- How do I show which commit is deployed without runtime shell execution?
- Stamp the commit SHA, branch, and build timestamp at CI time into a config value or generated file, for example config/app_version.php populated from an environment variable during the build. That answers 'which commit is deployed' with zero runtime shell execution and no repository access required inside the container. Reserve runtime git inspection only for the narrower question of whether the working tree has uncommitted changes in that environment.
- Is exposing git status over HTTP a security risk?
- Yes, if it is reachable. The bundle's entire purpose is rendering branch names, remote URLs, changed-file lists, and commit metadata into an HTTP response, which leaks repository structure and developer workflow detail. That is only acceptable when strictly gated to APP_DEBUG=true and non-public environments behind existing dev-only middleware. The Symfony toolbar's dev gating is a property you must reproduce deliberately in Laravel, not one you inherit.
- Will the runtime environment even have git or a .git directory available?
- Often not. Deployment artifacts built from a Dockerfile or CI archive typically exclude the .git directory, and slim runtime images usually do not ship the git binary, so a runtime status check silently returns nothing or throws. Build-time stamping sidesteps both problems entirely. Confirm this before estimating any reimplementation work, because it can invalidate the feature's premise.
- How much effort is it to reimplement this behavior in Laravel?
- Roughly half a day for an artisan command that resolves the repository root, runs git status --porcelain, truncates the changed-file list, and degrades gracefully when no repo exists. One to two days gets a polished Debugbar collector with tests and the same graceful-degradation behavior. The three behaviors worth extracting are repository root resolution, porcelain status parsing into a compact summary, and rendering into a dev-only surface.
- How should I sequence this work and what should I evaluate first?
- Start with a half-day spike to confirm the actual developer pain, either 'which commit is deployed' or 'are there uncommitted changes in this environment,' and whether Laravel Debugbar is already installed. The first question is better solved by CI stamping, so implement that before writing any runtime VCS inspection. Only build the runtime check if the uncommitted-changes signal proves genuinely useful, and check whether Debugbar, Ignition, or an artisan about-style command already covers most of the need.
Weaver
How can I help you explore Laravel packages today?