App Status Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. Before doing anything else, confirm that reality:

composer show vysokeskoly/app-status-bundle

You will see "type": "symfony-bundle" and requirements against symfony/framework-bundle / symfony/http-kernel. It has no Laravel service provider, no facade, no config publishing, and no auto-discovery. Laravel's package discovery will ignore it, and the collector it ships depends on Symfony's Profiler/DataCollector machinery, which Laravel does not run. Treat it as reference material, not a dependency.

If you are actually working in a Symfony app, the minimal path is:

1. composer require --dev vysokeskoly/app-status-bundle
2. Register it in config/bundles.php (or let Flex do it).
3. Ensure the profiler is enabled for the environment (framework.profiler in config/packages/dev/web_profiler.yaml).
4. Open the profiler toolbar on any request and look for the build-info panel.

Where to look first in the repo: the DataCollector class and whatever source it reads build info from (a generated file, env vars, or a service). The README is the only documentation; there is no docs site. The whole value of the package is small — expect a few hundred lines at most. Read the collector before trusting it.

First use case to evaluate against: "When I open the profiler on staging, can I see which git SHA / build timestamp / branch is actually running?" If that is what you want in Laravel, you will get there faster by writing ~80 lines yourself than by trying to port this bundle.

Laravel-side minimal replacement:

// app/Support/BuildInfo.php
final class BuildInfo
{
    public static function get(): array
    {
        return Cache::rememberForever('app.build_info', function () {
            $path = base_path('build.json');
            return is_file($path)
                ? json_decode(file_get_contents($path), true) ?: []
                : ['sha' => 'unknown', 'built_at' => null];
        });
    }
}

Then surface it via Debugbar, Telescope, a response header, or the health endpoint. That is the day-to-day leverage you actually get from this package's idea.

Implementation Patterns

If you are in a Symfony app

The bundle follows the standard collector pattern:

• A service tagged data_collector with an id and a template.
• A Twig template rendering the profiler panel.
• The collector is only invoked when the profiler is active (dev/test by default).

Typical integration is: build pipeline writes a file (e.g. var/buildinfo.json or build/buildinfo.json), the collector reads it, the panel displays it. Check the exact expected path/format in the collector source — the README does not spell it out, and a wrong path usually results in an empty panel rather than an error.

If you need to customize, the extension points are limited to:

• Overriding the Twig template via templates/bundles/AppStatusBundle/... (standard Symfony bundle override).
• Decorating the collector service in services.yaml.
• Not much else. There is no configuration tree worth mentioning.

If you are in a Laravel app (the realistic scenario)

Do not install the bundle. Reproduce the pattern:

1. Generate build metadata at deploy time, not at runtime.

# deploy.sh
printf '{"sha":"%s","branch":"%s","built_at":"%s"}' \
  "$(git rev-parse --short HEAD)" \
  "$(git rev-parse --abbrev-ref HEAD)" \
  "$(date -u +%FT%TZ)" > build.json

2. Expose it through a cached accessor (see BuildInfo above). Never read the file on every request.

3. Integrate with the tools you already have:

   • Laravel Debugbar: add a custom collector so the SHA appears in the debug bar.
   • Telescope: a small watcher or a Telescope::tag() call on requests.
   • Response header: middleware adding X-App-Build: <sha> is the cheapest possible version of this bundle's value and works in production.
   • Health endpoint: Laravel 11's /up route is the natural home; append build info to the JSON response for ops.

4. CI integration: run the deploy script in GitHub Actions / GitLab CI after checkout, before artisan config:cache. If you cache config before writing build.json, the accessor will cache "unknown" forever — see Gotchas.

5. Multi-environment: keep sha in all environments, but only expose branch/commit publicly in non-prod. In prod, a header or a protected endpoint is enough.

The general workflow this package encourages — "make deployed code identity visible to developers without SSH-ing into the box" — is worth adopting. The bundle itself is just one implementation of it.

Gotchas and Tips

• Zero stars, zero dependents, last release July 2022. There is no community validation and no evidence anyone else runs this in production. Treat it as unmaintained. Check whether it even installs against your Symfony version (6.4/7.x) before spending time on it.
• It cannot run in Laravel. The composer type, the DataCollectorInterface dependency, and the profiler requirement are all hard blockers. Any attempt to composer require it in a Laravel project risks dependency conflicts for no benefit.
• Profiler-only means dev-only. Even in Symfony, this shows nothing in production because the profiler is disabled there. If your actual goal is production build visibility, this bundle does not solve it — use a header, health endpoint, or Sentry release tagging instead.
• Missing build file = silent empty panel. Most collectors of this style do not throw when the source file is absent; you just get a blank panel and waste an hour. Verify the file exists and the path matches before debugging the bundle.
• Config caching: in Laravel, if you cache build.json into config or a Cache::rememberForever entry during the build step, a redeploy without a cache flush will show the previous SHA. Either flush the key in your deploy script or key the cache by file mtime.
• Do not leak build metadata publicly. Commit SHAs and branch names can aid attackers (they reveal repo structure and whether you are on a release branch). Keep the header/endpoint behind auth or restrict to internal networks in production.
• Extension points are thin. There is no config tree, no events, no contracts. Forking the collector is easier than decorating it. If you do fork, MIT license makes that trivially legal — just keep the attribution.
• Debugging tip for Symfony: if the panel does not appear, run bin/console debug:container --tag=data_collector | grep -i status to confirm the service is registered and tagged. If the tag is missing, the bundle was not enabled in bundles.php.
• Version pinning: if you do use it, pin an exact version ("vysokeskoly/app-status-bundle": "1.0.0") and add it to require-dev. A 2022 bundle is a supply-chain liability in require.
• The real takeaway: the bundle's entire feature set is roughly "read a JSON file and render it in a debug panel." Reimplement it in whatever framework you use; you will end up with something smaller, maintained, and tailored to your deploy pipeline.