Version Information Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony bundle, not a Laravel package. There is no service provider, no config file to publish, no facade. If the job is Laravel, the package is not installable — treat it as a reference implementation and read the two collector classes for the idea, or just use git status in a terminal.

If you are on Symfony 2.x/3.x:

1. composer require --dev leaseweb/version-information-bundle
2. Register only in the dev environment (AppKernel::registerBundles() inside the if ('dev' === $this->getEnvironment()) branch, or config/bundles.php guarded by $env === 'dev').
3. Ensure framework.profiler and web_profiler.toolbar are enabled — the bundle adds a toolbar panel and a profiler panel; without the toolbar it is invisible.
4. Look first at DependencyInjection/Configuration.php in the vendor directory. That file is the only authoritative list of config keys (repository path, VCS type, whether to run status vs log), and the README is thin enough that you will end up there anyway.
5. Point the bundle at your repository root if the Symfony kernel root is not the repo root (common with a app/ or src/ layout, or a monorepo).

First useful use case: you are clicking through a dev site on a branch, and you want a permanent reminder of which branch and how dirty the tree is without alt-tabbing. Open any page, expand the toolbar, read the status block. That is the whole value proposition — a one-glance working-tree summary attached to the request you are already looking at.

Implementation Patterns

Dev-environment-only wiring. The single most important pattern: gate registration on the environment. The collector shells out on every profiled request, and it exposes repository metadata. Keep it out of prod and out of test unless you specifically want it.

// app/AppKernel.php (Symfony 2/3 style)
if (in_array($this->getEnvironment(), ['dev'], true)) {
    $bundles[] = new Lsw\VersionInformationBundle\LswVersionInformationBundle();
}

Treat it as a "dirty tree" indicator, not a version source. Do not read branch/commit from this bundle in application code — the collector is a debug artefact. For build stamps, inject a generated file at deploy time (config/version.php) or use composer show output. The bundle answers "is my tree dirty right now?", not "what is deployed?".

Multi-repo setups. If your app spans vendor forks or sibling repos, the pattern is decoration rather than configuration: register your own DataCollector that calls the bundle's collector for each path, or wrap the existing collector in a service decorator and append results. Adding a second toolbar panel per repo gets noisy fast — one panel with a list of path => status is the readable shape.

Cache the shell-out. The naive implementation runs git status on every request. In dev with a warm browser tab and a large repo that is noticeable. A practical pattern is a small decorator that memoises the result for ~5–30 seconds keyed by repo path, or a kernel.request listener that populates a cache the collector reads. This is the extension point worth building; the rest of the bundle is small enough to read in one sitting.

Pair with the profiler, not just the toolbar. The toolbar shows a truncated summary. When something looks odd (untracked files missing, submodule noise), open the full profiler panel for the request — it has the untruncated command output, which is also the fastest way to confirm the command actually ran in the directory you expected.

Sanity-check the command yourself. Whatever the bundle runs, run the same thing from a shell as the web user:

sudo -u www-data git -C /path/to/repo status --porcelain

If that fails, the bundle fails, and it will fail silently or with a generic "no information" panel.

Gotchas and Tips

• Archived since 2016-01-13. No fixes, no security patches, no Symfony 4/5/6 support. The collector almost certainly implements DataCollectorInterface::collect(Request $request, Response $response, \Exception $exception = null), which changed in Symfony 4.4 (\Throwable) and dropped getRequest() in 5.0. Expect to patch or fork on any modern Symfony.
• It is not a Laravel package. No Illuminate\Support\ServiceProvider, no config/version-information.php. Score 0.1875 and zero dependents reflect that nobody is maintaining this against current stacks.
• Shell execution is the whole risk surface. shell_exec/exec may be disabled in php.ini, and the PHP-FPM user often has a different PATH than your shell — git may be missing entirely. Prefer absolute paths in config if the bundle supports it; if not, that is your first patch.
• Never enable in production. The toolbar and profiler are dev tools; leaving them on leaks repository paths, branch names, and uncommitted file names to anyone who finds /_profiler.
• Large repos are slow. git status on a repo with a huge tree, submodules, or a network filesystem can take seconds. Combined with "run on every request", that turns dev browsing into a crawl. Use --porcelain (if configurable) and consider status.showUntrackedFiles=no.
• Windows and SVN. Path separators and the SVN client's output format differ; SVN status against a network share is especially slow. The bundle's SVN support was written for a specific workflow — verify before relying on it.
• Output escaping. File names are attacker-influenced in a shared repo (a branch or filename can contain HTML-ish characters). If you template-override the panel, escape with {{ ... }} and never |raw.
• Config key discovery is manual. The README is minimal and the repo is archived; read DependencyInjection/Configuration.php and DependencyInjection/*Extension.php in vendor/ to find the real keys. Anything you read online about this bundle's config is likely stale.
• Debugging order when the panel is blank: (1) is the bundle registered in the current env, (2) is web_profiler enabled and is the toolbar rendering at all, (3) does the configured path exist from the web user's perspective, (4) does the VCS binary exist on that user's PATH. Most "it doesn't work" reports are step 3 or 4.
• The honest recommendation: the useful idea here is one toolbar line answering "branch + dirty?". You can reproduce it in ~80 lines with a DataCollector and a Twig toolbar template on a supported Symfony version, without inheriting an abandoned dependency. Adopt the pattern, not the package.