System Information Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is not a Laravel package, and that is the single most important finding. kmi/system-information-bundle is a Symfony bundle built for Sonata Admin, registering through Symfony's kernel/bundle registry and rendering a dashboard block via Sonata's Twig templates. Laravel has no bundle registry, no Sonata Admin, and no Doctrine admin layer, so there is no architectural seam where this drops in. For a Laravel codebase the fit is effectively zero; the only transferable artifact is the idea — a panel surfacing PHP version, extensions, OS, disk headroom, memory, and environment name — plus the field list and layout, not the code as a dependency.

Integration feasibility. Not merely awkward — likely impossible on a modern Laravel runtime. Archived Sonata bundles of this vintage pin PHP 5.6/7.x and Symfony 2.8/3.x constraints, while Laravel 10/11 require PHP 8.1+. Composer will refuse resolution, and forcing it drags in sonata-project/admin-bundle, sonata-project/block-bundle, Twig, and Doctrine — hundreds of transitive packages that collide with Laravel's pinned Symfony components. Reimplementing the panel natively is on the order of 1–2 developer-days; forcing this bundle in is unbounded effort with negative residual value.

Technical risk. High and one-directional. The repository is archived: no security patches, no PHP 8 compatibility fixes, no framework version tracking. That is a supply-chain and maintenance liability with no offsetting benefit. The bundle also touches sensitive surface — server paths, PHP config, disk and memory details, environment values — so an unmaintained renderer in an admin panel is a standing information-disclosure risk with no upstream to remediate it. With 0 stars and 0 dependents there is no community corpus of fixes to lean on either; the due-diligence signal is a clean reject.

Key questions.

• What decision does this panel actually inform — audit/compliance evidence, ops visibility, or developer convenience?
• Does the org already run an admin surface (Nova, Filament, Backpack) where a native widget is trivial?
• Is there any Symfony/Sonata footprint in the estate where the bundle would be viable? If not, it is out of scope entirely.
• Are we solving "what is installed on this host" (php artisan about, health-check packages) or "what is happening on this host" (Pulse/monitoring)? These are different tools with different owners.
• Where does environment/version context live in the product roadmap, and is it a widget, an Artisan command, or both?
• Who owns the code if we fork it, and what is the review cadence?
• Which fields, if any, should be permission-gated or excluded for privacy/compliance reasons?

Integration Approach

Stack fit. Poor by construction. The correct stack fit is Symfony + Sonata Admin; the target stack is Laravel. Treat the repository as a reference specification, not a component. The concrete artifacts worth harvesting are the enumeration of metrics it displays and its layout — both reproducible in Blade or a Filament/Nova widget in a fraction of the time it would take to justify a Sonata dependency.

Migration path. Extract-then-rebuild:

1. Read the bundle's DI extension and its Sonata Admin subclass to enumerate the exact fields it surfaces (that class is where data collection lives).
2. Map each field to a Laravel-native source — php artisan about, PHP_VERSION/get_loaded_extensions(), disk_free_space(), config('app.version'), DB/queue/cache driver config, last deploy SHA, last migration timestamp.
3. Implement as a service provider plus a Blade component or Filament/Nova widget, rendered behind existing admin authorization and a dedicated gate.
4. Retire the repo from any dependency manifest; keep it as an internal reference link only.

Compatibility. Near-zero as-is: PHP constraint mismatch, Symfony major mismatch, Sonata major mismatch, no Laravel service provider, no package auto-discovery. Any "compatibility layer" amounts to a rewrite of the package, at which point the package is no longer in the picture. Validate the finding by attempting composer require in a scratch Laravel app — an immediate resolution failure is the documented outcome.

Sequencing. (1) Spike: audit the repo, confirm the field list and Composer constraints — about half a day. (2) Decision memo: native rebuild vs. adopt a maintained health package (spatie/laravel-health, Pulse). (3) Build the native widget and php artisan system:info command — 1–2 days. (4) Wire into admin auth, add to the ops runbook, publish which fields are exposed. (5) Only if a Symfony/Sonata service exists elsewhere, evaluate the bundle there as a separate, independent workstream with its own owner.

Operational Impact

Maintenance. Zero upstream maintenance — archived means every future PHP/Laravel upgrade is ours if vendored. Adopting it means owning a permanent fork; that is a standing tax on a feature that is otherwise a few hundred lines of Blade and PHP. The correct ownership model is "internal snippet, no dependency," owned by the team that owns the admin surface.

Support. No vendor, no community, zero stars, zero dependents — no one to escalate to and no downstream fixes to search. Internal on-call owns it end-to-end. Contrast with maintained alternatives (spatie/laravel-health, Laravel Pulse, php artisan about) that track framework versions and accept issues. Support-ticket deflection is real but modest: a system-info panel measurably reduces "what version/environment are you on?" ping-pong, which is the concrete value justifying 1–2 days of build.

Scaling. Negligible load — a read-only informational panel, not a hot path. The only scaling concern is cost of access: if it stats the filesystem or shells out per dashboard render, cache the payload (5–15 minutes) so a busy admin page does not repeatedly probe the host. No horizontal-scaling implications.

Failure modes.

• Install/resolution failure — the most likely outcome; surfaces as a Composer conflict, not a runtime bug.
• Autoload and class collisions between Sonata's Symfony component versions and Laravel's.
• Privilege/permission errors reading /proc, disk, or environment data, throwing inside the admin dashboard.
• Information disclosure — server paths, PHP config, and environment details rendered to users who should not see them; must sit behind admin authorization and stay off any public route.
• Silent staleness — an unmaintained panel quietly reports wrong data after a PHP upgrade with no error signal.

Ramp-up. Reimplementing the capability in Laravel is low-ramp for any mid-level Laravel developer; php artisan about is the starting point and the bundle's field list is the delta. Ramping a team onto Sonata Admin purely to consume this bundle is a multi-week detour with no residual value to a Laravel shop. Net recommendation: do not adopt as a dependency; harvest the field list, capture the panel on the admin backlog, and build natively — the 0.065 score and archived status are consistent with a package whose only remaining use is as a design reference.