App Status Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and category-mismatched. Despite being evaluated against a Laravel/PHP requirement, vysokeskoly/app-status-bundle is a Symfony bundle, not a Laravel package. It registers a Symfony DataCollector (tagged data_collector) that injects build metadata into the Symfony Web Profiler. Laravel does not ship the Symfony Profiler bundle, so there is no host application component for this collector to attach to. Laravel's equivalents are Telescope (Watchers) and barryvdh/laravel-debugbar (Collectors) — different extension contracts entirely.

Integration feasibility — low as-is, viable as a reference implementation. A direct composer require would only make sense inside a Symfony application with symfony/profiler-pack installed. For Laravel, the realistic path is to read the collector's source (~100–200 lines) and reimplement the build-info retrieval as a Telescope watcher or Debugbar collector. The useful, portable asset here is the idea and the metadata-sourcing logic, not the package itself.

Technical risk — high. Zero stars, zero dependents, and no release since 2022-07-15 indicate no production validation and likely stale Composer constraints (probable symfony/framework-bundle pins against 4.4/5.x). Laravel 10/11/12 resolve Symfony 6/7 components, so a hard constraint conflict is likely. Single-org maintenance implies a bus factor of one, and the opportunity score (35.26) corroborates weak ecosystem pull. MIT licensing is clean; that is the only low-risk dimension.

Key questions

• Is there any Laravel-targeted variant, or is this Symfony-only by design?
• What exactly constitutes "buildinfo" — git SHA, semver, build timestamp, CI job ID, or a static JSON artifact?
• Does it degrade gracefully when build metadata is absent, or does it throw during dev requests?
• Which Symfony versions do the composer.json constraints permit?
• Is the collector strictly dev-gated, or can it be enabled in production and leak build/commit metadata?
• Is there any test coverage, or is the README the entire contract?

Integration Approach

Stack fit — misaligned; treat as a pattern source, not a dependency. The requirement it addresses ("surface build provenance during local debugging") is legitimate and cheap to satisfy natively in Laravel. I would not add this package to a Laravel composer.json under any configuration.

Migration path — none required; this is a greenfield port. Recommended sequence:

1. Define the metadata contract (commit SHA, branch, semver, build time, CI run URL) and its source of truth (env vars injected at deploy, or a generated build.json).
2. Implement a small BuildInfoCollector as a Debugbar collector for local DX, and/or a /health or /version JSON endpoint for non-prod environments.
3. If a Telescope watcher is preferred, wrap the same metadata provider so both surfaces share one service.

Compatibility. Before any code is written, inspect the bundle's composer.json for symfony/* version pins — this is the most probable blocker and the fastest disqualifier. Its DependencyInjection/ extension and Resources/config/services.xml idioms translate conceptually to a Laravel service provider, but not mechanically.

Sequencing. (a) Validate the underlying requirement with the team — 15-minute exercise. (b) Inspect source for metadata-sourcing ideas only. (c) Build the native Laravel collector/endpoint (~1–2 days). (d) Only run a Symfony spike if a second Symfony-based service is genuinely in scope; otherwise skip the package entirely.

Operational Impact

Maintenance. Unmaintained since mid-2022 with no dependents means any adoption becomes an implicit fork. Upgrading Symfony majors would require patching the bundle ourselves, and the Laravel path adds a permanently owned internal component — small, but ours.

Support. No community, no issue triage, no documentation beyond a README. Internal ownership and an internal README are prerequisites. There is no upstream to escalate to.

Scaling. Negligible — profiler collectors execute only in dev/debug mode and add no production runtime cost. The only scaling-adjacent concern is if build info is promoted to a production health endpoint, which should be a separate, deliberately designed surface with caching.

Failure modes.

• Composer resolution failure against modern Symfony components (highest likelihood).
• Collector exception during boot breaking every dev request — dev-only blast radius, but high friction.
• Stale build metadata if the source artifact is generated at build time but not regenerated on hotfix deploys.
• Information disclosure if the profiler or metadata endpoint is reachable in production (commit SHA, internal CI URLs).
• Silent abandonment: no security patches, no PHP 8.4+ compatibility work.

Ramp-up. Low technical effort — the codebase is small and readable — but it requires Symfony Profiler familiarity that a Laravel-centric team likely lacks, converting a trivial feature into a knowledge-transfer task.

Recommendation: Do not adopt. Reimplement the 50–100 lines of metadata collection natively in Laravel (Debugbar collector plus a gated version endpoint). Retain the package only as a design reference, and revisit solely if a Symfony service enters the estate.