Tablebundle Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office data grids. Still a bounded, MIT-licensed implementation of server-rendered tables — useful as a scoping reference for what an in-house table component must cover (column config, sorting, pagination, filter rendering, output) rather than as a dependency to adopt.
• Progressive-enhancement / no-JavaScript strategy. Unchanged: the package supports the decision to keep critical tables (admin lists, printable reports, invoice/statement views, emailed HTML digests, low-bandwidth or kiosk environments) fully server-rendered, with JS as an optional enhancement layer.
• Accessibility and crawlability roadmap items. Unchanged: server-rendered tables are friendlier to screen readers, print stylesheets, and non-browser consumers (PDF/HTML exports, scrapers, email clients) — a defensible argument when prioritizing an a11y workstream.
• Legacy Symfony maintenance triage. Still a candidate "reuse instead of rebuild" input for an internal admin tool on Symfony 2.x/3.x — but adoption remains fork-and-own, not a vendor decision.
• Ecosystem-fit validation. The brief frames this as a Laravel/PHP package; it is a Symfony bundle using Twig (the filter Twig function is now confirmed as part of its rendering surface). Any Laravel-side need must be met by a Blade-plus-controller pattern or a Laravel-native grid package; this repo stays excluded from Laravel dependency evaluation.
• Maintenance-signal re-check (new). A patch release (v1.3.3) has appeared after a long gap, so the package is not strictly dormant — but a single community-contributed bugfix is not evidence of a support commitment. It downgrades "abandoned" to "sporadically maintained by drive-by contributors," which does not change the adoption recommendation.
• Release-discipline risk (new). v1.3.3 renames the public method getActiveFilter() → getActiveFilters() in a patch release. That is a breaking change under SemVer, confined to a narrow (and previously typo-named TablieView) API. It is direct evidence that consuming this package means pinning, forking, and owning the call sites.
• Market-gap evidence. Low adoption plus a real, recurring need (no-JS tables) still supports a roadmap bet on a maintained successor rather than on this artifact — though the gap is now framed as "no maintained option," not "no living code."

When to Consider This Package

Consider it only when all of the following hold:

• You are on a legacy Symfony 2.x/3.x codebase (PHP 5.6–7.x) where the bundle's API already matches your framework version — and you have audited call sites for getActiveFilter(), which now fatal-errors in favour of getActiveFilters().
• The requirement is genuinely read-only, server-rendered tabular output with filter rendering via Twig, and no client-side sorting, filtering, or live refresh.
• You are comfortable vendoring or forking the code and assigning an owner, and you pin to an exact version — the v1.3.3 rename shows patch releases can break consumers.
• You need it as a reference implementation to inform an internal design, not as a long-lived runtime dependency.

Look elsewhere when:

• The stack is Laravel (this will not install or integrate) — use a Laravel-native grid/admin package or Blade + a small table partial.
• You are on modern Symfony — EasyAdmin, Symfony UX components, or an actively maintained Twig table bundle are the better fit.
• You require a support commitment, security-patch SLA, PHP 8+ guarantee, or CI — the v1.3.3 bugfix thread shows community goodwill, not a maintained release process.
• You need client-side interactivity (column sort, filter, inline edit, virtualized rows) — a no-JS bundle is the wrong tool by construction.
• Your procurement or compliance process requires maintainer due diligence — low star/dependent counts will not clear a dependency-review gate, and a breaking change in a patch release is a red flag in that review.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Symfony bundle that renders data tables entirely on the server, with no JavaScript. The concept is valuable — it maps to accessibility, printable/exportable reports, and low-bandwidth users. The artifact has just received a community bugfix release, which is welcome but is not a maintenance commitment: no roadmap, no support path, no release discipline (the patch release renames a public method). Recommendation is unchanged: treat it as design input, not a purchase or a dependency. License cost is zero; ownership cost is non-trivial and the risk is unpatched code in a production path. The strategic read — that a maintained no-JS table capability is an unmet need worth a small internal build — still holds.

To engineering: It is a Symfony/Twig bundle, not a Laravel package — keep it out of Laravel dependency reviews. If we have a legacy Symfony admin surface, lift the column/render/filter model and reimplement it in about a day; do not add it to composer.json on a supported branch. If anyone does vendor it, pin the exact version and patch getActiveFilter() → getActiveFilters() at our call sites — v1.3.3 broke that API in a patch release, so assume no SemVer protection going forward. For new work, use EasyAdmin or a Twig partial, and carry forward the actual decision: no-JS by default, enhance with JS.