Table Bundle Laravel Package

Technical Evaluation

Framing mismatch (critical): The request frames this as a Laravel/PHP package. whatwedo/table-bundle is a Symfony bundle — its architecture is built on Symfony's packaging primitives (bundle class, DI extension, compiler passes, configuration tree, Twig extension). It is not Laravel-native and cannot be composer required into a Laravel application and used idiomatically.

Architecture fit:

• Symfony stack: Reasonable fit by construction. Tables are typically modeled as PHP classes (table definition + column/type objects) rendered through a Twig extension, which matches Symfony's service-container-first design and lets table definitions be injected and unit-tested.
• Laravel stack: Poor. Laravel's equivalent primitive is the service provider, and there is no bundle/extension/config-tree lifecycle. Adopting this would mean pulling symfony/framework-bundle and a Twig runtime into a Laravel app — introducing a second kernel, a second view engine, and a competing set of symfony/* constraints alongside Laravel's own transitive Symfony dependencies. The glue code would likely exceed the cost of writing Blade/Livewire table components directly.
• Framework-agnostic PHP: Not applicable; the value is in the Symfony/Twig integration, so the framework dependency is not incidental — it is the package.

Integration feasibility: Low for Laravel, moderate for Symfony. There is no evidence of a Symfony Flex recipe (5 stars, 0 dependents), so registration and configuration would be manual. The core table DSL is probably usable, but every surrounding concern — routing, request parameter binding for sort/page/filter, view rendering — would need to be wired by hand. Budget a spike before committing; do not assume the README is complete.

Technical risk (high):

• Adoption signal is the headline risk. 5 stars, 0 dependents, no downstream projects to observe. There is no community proof that this survives contact with real applications.
• Bus factor / abandonment. Single-vendor package ("whatwedo"), likely maintained for internal use and open-sourced as a byproduct. No stated support model, no visible security policy, and an opportunity score of ~26 is consistent with a dormant or narrowly-scoped project.
• Scope is deceptively deep. Table generators accumulate edge cases: pagination boundaries, multi-column sort, filter composition, column type rendering/escaping, exporters, empty states, and test coverage for all of it. A small package has few places to hide bugs.
• Upgrade treadmill. Symfony majors deprecate container and Twig APIs regularly; an unmaintained bundle becomes a hard blocker on framework upgrades.
• No CVE process. Table rendering touches user data and output escaping; absence of a disclosure channel means you are the security team.

Key questions to answer before any commitment:

1. Last commit date, open-issue count, and release cadence — is this active or archived?
2. Which Symfony and PHP versions are supported, and are constraints pinned pessimistically?
3. Does it do server-side pagination/sorting/filtering (DB-level LIMIT/ORDER BY) or in-memory array slicing? The latter is a scaling non-starter.
4. What is the Twig coupling — does it require symfony/twig-bundle, or is the rendering layer separable?
5. Is there a test suite, and what is its coverage of column types and pagination edge cases?
6. Are exporters, bulk actions, and row-level authorization in scope, or would we build them?
7. Is there a documented extension point for custom column types, or would we patch the vendor tree?
8. What is the license/attribution expectation for a fork? (MIT permits forking — confirm we are willing to own it.)

Verdict: Not viable as a Laravel dependency. Viable as a reference implementation for a Symfony shop with an appetite to fork-and-own. Otherwise, prefer maintained alternatives or a purpose-built component.

Integration Approach

Stack fit: Target environment is Symfony (with Twig). Outside that, there is no clean fit. Concretely:

• ✅ Symfony + Twig + Doctrine (or any repository layer) — native.
• ⚠️ Symfony without Twig (API-only) — only if the rendering layer is separable; verify.
• ❌ Laravel — requires a Symfony/Twig bridge, duplicate kernel, and dependency-conflict management against illuminate/*'s existing symfony/* pins. Reject unless there is a non-negotiable functional requirement.
• ❌ Standalone PHP — the package's value is the framework integration.

Migration path (Symfony): Incremental and page-scoped. Table definitions are declarative classes, so migration is naturally per-screen: pick one low-traffic admin list view, define the table class, render it, compare output against the incumbent, then repeat. Do not attempt a big-bang migration of an admin surface — you would be rewriting every table against an under-documented DSL simultaneously.

Compatibility:

• Pin the package to a specific Symfony minor and record the constraint in composer.json; do not float.
• Audit composer why-not for Twig and symfony/http-foundation conflicts before merging.
• Verify the package's own constraints are not * or overly permissive — permissive constraints on an unmaintained bundle are how silent breakage enters.
• Confirm PHP version support against the platform's runtime; an old php constraint blocks upgrades.
• For Laravel specifically: expect symfony/framework-bundle to pull an HTTP kernel that competes with Laravel's; this is a hard conflict, not a nuisance.

Sequencing:

1. Spike (1–2 days): install in a throwaway Symfony app; build three representative tables (paginated list, filtered list with a relation join, custom-rendered column). Measure query counts.
2. Evaluate alternatives in parallel: Symfony — EasyAdmin, SonataAdmin, or a thin custom Twig macro layer; Laravel — Filament, Livewire tables, or spatie/laravel-query-builder + Blade components.
3. Decide fork-vs-adopt: if the spike succeeds but activity is stale, adopt with an explicit internal fork policy and a named owner.
4. Pilot on one screen, behind a feature flag, with output-diffing against the incumbent.
5. Roll out screen by screen; keep the incumbent path until the pilot has run a full release cycle.
6. Laravel: stop at step 2 unless a blocking requirement forces otherwise.

Operational Impact

Maintenance: The real cost is ownership, not licensing. MIT permits a fork, and given the activity signals, assume you will fork within 12 months. That means: vendor the package or maintain an internal fork branch, add it to the dependency-upgrade runbook, and assign a named owner. Budget roughly 1–2 days per Symfony major upgrade for rebase and regression testing, plus ongoing triage.

Support: None commercially, no SLA, no visible security-disclosure channel, and a community too small to have answered questions on Stack Overflow. Internal expertise is the only support channel. Treat every bug as yours to fix.

Scaling:

• Rendering itself is cheap (server-side HTML, memory proportional to page size). The risk is query behavior: if the abstraction issues per-row or per-column queries, a page of 50 rows across related columns can become 100+ queries.
• Verify pagination is pushed to the datastore (LIMIT/OFFSET or keyset), not applied to a fully hydrated collection. If it is the latter, the package does not scale past small tables regardless of infrastructure.
• "Export all" / unpaginated modes are the classic memory cliff — cap or disable them.
• Caching rendered fragments is a viable mitigation for read-heavy admin surfaces.

Failure modes to plan for:

• Silent breakage on framework upgrade — deprecation warnings in DI or Twig that only surface at runtime; mitigate with a smoke-test suite over each table definition.
• Dependency conflict at install — a Twig or http-foundation constraint clash blocks unrelated upgrades; mitigate by pinning and testing in CI.
• Output escaping regressions — a custom column type that bypasses Twig autoescaping is an XSS vector; audit any raw-render path.
• Pagination/filter state bugs — off-by-one, filter state lost on page change, sort parameters not preserved; these are user-visible and common.
• Authorization gaps — table definitions often expose columns or rows the caller should not see; enforce per-column and per-row visibility server-side, not in the template.
• Abandonment — no upstream fix for a CVE; the fork becomes mandatory on your timeline, not theirs.

Ramp-up: Low ceiling, thin documentation. A developer familiar with Symfony and Twig should reach productive use in roughly half a day to a day, most of which is reading source rather than docs (expect to learn the column/type DSL and rendering pipeline by inspection). For a Laravel team attempting the bridge, estimate 3–5 days just to reach a working proof of concept, with a meaningful chance of abandoning it — and that time is better spent on a native component. Include the package in onboarding material; undocumented DSLs decay into tribal knowledge otherwise.

Bottom line for a TPM: the total cost of ownership is dominated by the fork obligation and framework-upgrade tax, not by integration. That is only justified if the package's table DSL saves materially more per screen than the ~1–2 days to build equivalent Blade/Twig components in-house — and with 5 stars and 0 dependents, that case is not made.