Stats Table Bundle Laravel Package

Technical Evaluation

Architecture fit: low. igraal/stats-table-bundle is a Symfony bundle, not a Laravel package. That distinction is the central finding of this assessment. Symfony bundles are a first-class extension mechanism built on the Symfony HttpKernel: they ship a Bundle subclass, a DependencyInjection/*Extension class, services.yaml definitions, compiler passes, and are registered in config/bundles.php. Laravel has no equivalent concept. It uses its own service container, service providers, and HTTP kernel. A Composer install will succeed at the file level but will produce no framework wiring — no routes, no container bindings, no config, no facade. Nothing will "just work."

The one genuine overlap is symfony/http-foundation, which Laravel depends on transitively (Illuminate\Http\Request extends Symfony\Component\HttpFoundation\Request). That makes some low-level value objects potentially compatible, but it does not make the bundle's integration layer portable.

Integration feasibility: low, with one narrow path. The only viable approach is to treat the package as a source of domain logic, not a dependency. That requires: (a) reading the source to determine whether any meaningful logic lives outside Symfony-specific classes, (b) forking or vendoring that logic, and (c) writing a Laravel ServiceProvider wrapper plus a published config file. Whether step (a) yields anything is unknown from the repository metadata alone — the name suggests the bundle may be thin glue over an external "stats-table" library, in which case the bundle is nearly worthless and the underlying library is the real target.

Technical risk: high. The adoption signals are uniformly negative and mutually reinforcing:

An unstarred, zero-dependent package from a single vendor namespace is either an internal tool published by accident or an abandoned experiment. Both are the same risk to us: we would be the sole consumer and the sole maintainer. There is also a supply-chain consideration — pulling in an unvetted, zero-adoption package into a production Laravel app is a decision that requires explicit security review, not a composer require.

Key questions to resolve before any code is written:

1. What does "stats-table" actually mean here — server-side aggregation, HTML table rendering, an admin UI, or a data-transfer format?
2. Is the bundle a thin wrapper around a separate, framework-agnostic package? If so, evaluate that package instead and ignore this repo.
3. What are the PHP and Symfony version constraints? Do they conflict with the Symfony component versions Laravel has pinned?
4. What is the license, and is the vendor (igraal) still active?
5. Does it depend on Twig, Doctrine, Symfony Forms, or an ORM layer we do not run?
6. Are there tests, and do they pass? A package with no CI is a package with no verified behavior.
7. Is this a fork of a better-maintained project?

Integration Approach

Stack fit: poor for direct consumption, plausible for extraction. Do not plan an install-and-configure integration. Plan a discovery-and-reimplement integration, with a hard decision gate.

Migration path (recommended sequence):

1. Source audit spike (1–2 engineer-days). Clone the repo, run composer show, inspect composer.json for constraints, read the Bundle class and DI extension, and enumerate every class by whether it is framework-coupled or plain PHP.
2. Decision gate. If fewer than a meaningful handful of classes are framework-agnostic, stop — the cost of extraction exceeds the cost of building or buying the capability directly.
3. Extraction. Vendor the reusable classes under our own namespace (or fork under an internal org), strip Symfony-specific wiring, and replace it with a Laravel ServiceProvider, a publishable config file, and container bindings.
4. Adapter, not rewrite. If the bundle exposes an interface we can implement, write a Laravel-side adapter behind that interface so the domain logic is swappable later. This preserves the exit ramp.
5. Parity testing. Any behavior we depend on must be covered by our own tests. Upstream will not provide regression coverage for us.

Compatibility. Expect Composer resolution friction. Laravel 10/11 pin Symfony 6/7 components; a bundle written against Symfony 3/4/5 will either refuse to install or will install a second, conflicting copy of shared components. Even where resolution succeeds, version drift is a silent failure mode, not a loud one. Verify constraints explicitly rather than trusting a successful composer update.

Sequencing. Run this behind a feature flag and in parallel with an evaluation of alternatives. Realistically one of three outcomes: (a) the bundle's logic is trivially extractable and worth ~1 week; (b) it is thin glue and we should build the capability ourselves or adopt a Laravel-native package; (c) it is framework-entangled and we abandon it. The default answer is (c) until the spike proves otherwise. Timebox aggressively — this package's adoption profile does not justify open-ended investigation.

Recommendation: Treat this as a build-vs-buy-vs-extract decision, not an integration task. Assign zero integration engineering until the spike returns.

Operational Impact

Maintenance: we own it outright. A zero-dependent package has no downstream pressure to keep it working. If igraal stops committing — and the metadata suggests they already have — we inherit full maintenance, including PHP version bumps, Symfony component upgrades, and security patches. Budget for this as a permanent internal fork, with a named owner and a documented patch policy, not a one-time integration cost.

Support: effectively none. No stars means no community. No documented API means no reference material. No dependents means every edge case we hit is one nobody has hit publicly before. Ramp-up cost for a new engineer is high: they must learn Symfony bundle conventions — DI extensions, compiler passes, tagged services, event subscribers — to read code that does not run in their framework. Estimate 2–3x the onboarding time of an equivalent Laravel-native package, and plan for a knowledge silo unless we document the extracted logic ourselves.

Scaling: unverified and dependent on the underlying implementation. The metadata gives no performance characteristics. Two scenarios matter: if the bundle does server-side rendering of HTML tables, throughput is bounded by the request cycle and pagination quality; if it performs aggregation queries, scaling depends entirely on the data layer, which the bundle may assume is Doctrine — a mismatch for Eloquent. Neither concern can be assessed without the source audit. Flag performance as an open risk with no mitigation until measured.

Failure modes to plan for:

• Composer conflict on framework upgrade — Laravel major upgrades bump pinned Symfony components; the vendored package's constraints may block the upgrade or install a duplicate. Mitigate by forking and relaxing constraints under our control.
• Silent framework drift — code paths relying on Symfony kernel behavior that Laravel does not replicate; tests pass, production behavior differs. Mitigate with integration tests against the Laravel kernel specifically.
• Security scanner flag — an abandoned dependency will surface in SCA tooling and require an explicit, documented exception or removal. Plan the exception before it blocks a release.
• Bus factor of one — a single internal engineer understands the extracted code. Mitigate with written design docs and pairing.

Ramp-up estimate: ~1 week of extraction work plus ~1 week of adapter, tests, and documentation, conditional on the spike finding reusable logic. If the spike fails, total sunk cost is 1–2 days.

Bottom line for the TPM: the score, stars, and dependents are not noise — they are the assessment. An unadopted Symfony bundle is a poor fit for a Laravel stack on architecture grounds alone, and the adoption signals remove any argument for absorbing the maintenance risk without a compelling capability return. Run the two-day spike, hold a go/no-go gate, and assume the answer is no until the source proves otherwise.