- Is povs/lister-twig-bundle a Laravel package?
- No. Despite being catalogued alongside Laravel/PHP packages, this is a Symfony bundle: the Bundle suffix, the povs vendor namespace, and the Twig/Ajax list-type model all point to Symfony's HttpKernel bundle system. It expects registration in config/bundles.php, compiler passes, service tags, and Twig as the view layer. Laravel provides none of that substrate, so treat any Laravel listing of this package as a catalogue error.
- How do I install povs/lister-twig-bundle in a Symfony application?
- Run composer require povs/lister-twig-bundle, register the bundle in config/bundles.php, and add its configuration. It is a thin presentation layer over povs/lister-bundle, so that core bundle should already be installed and configured in the application. Because the package has no releases or CI evidence, pin an explicit version and confirm it actually installs under your PHP runtime before writing feature code.
- Does povs/lister-twig-bundle work with Laravel?
- Not without a bespoke shim. There is no Laravel service provider, no publishable config, no facade, and no Blade view layer, so you would have to bootstrap a Symfony container alongside Illuminate and add rcrowe/twigbridge just to get Twig in. That introduces a second thinly maintained dependency to justify the first, which is not a defensible plan. Use the package as a design reference in Laravel, not a dependency.
- What are the best Laravel alternatives to povs/lister-twig-bundle?
- The transferable idea is the list abstraction: separate the data source, filters, sorters, paginator, and column definitions from rendering, then swap presentation strategies. In Laravel that maps cleanly onto Livewire components with Blade, Filament tables, or Inertia-driven tables, all of which have active maintainers and framework-native ergonomics. Any of those gives you paginated, filterable, sortable table UI without a Symfony container in the stack.
- What is the difference between the Twig and Ajax list types?
- They are two interchangeable presentation strategies over the same list definition. The Twig type renders full list markup server-side through Twig templates, while the Ajax type serves list fragments for XHR requests so a page can refresh or paginate a table without a full reload. Keeping rendering separate from the data source, filters, sorters, paginator, and column definitions is the pattern worth borrowing even if you do not adopt the package.
- Which PHP and Symfony versions does povs/lister-twig-bundle support?
- There is no CI or release history, so support is an open question rather than an assumption. Reconcile the bundle's composer constraints against your application lockfile before anything else and expect conflicts, particularly around Twig major versions and Symfony contracts. Confirm the package installs under your target PHP runtime in a throwaway Symfony app before planning any adoption.
- Is povs/lister-twig-bundle maintained and safe for production?
- Zero stars, zero dependents, and a composite score of zero are not cosmetic: they mean no downstream validation, no community bug surface, and no evidence of an active maintainer. Abandoned packages also fall outside advisory coverage such as Roave Security Advisories, so they become a supply-chain concern and a compounding upgrade tax. The MIT license is the one unambiguously low-risk element, which makes forking legally clean if you decide to adopt.
- What configuration does povs/lister-twig-bundle need from povs/lister-bundle?
- This bundle only supplies Twig template helpers and rendering support, so the real configuration lives in the underlying lister bundle: data sources, filters, sorters, paginator settings, and column definitions. You define list types there, then choose Twig or Ajax rendering in your templates. Before committing, confirm the core bundle itself is maintained rather than assuming this bundle is a thin skin over an equally stale dependency.
- Does povs/lister-twig-bundle have tests or CI?
- There is no visible CI, release tagging, or test suite, so installability and PHP 8.x compatibility are unproven. Time-box a one to two day spike in a throwaway Symfony app purely to establish that it installs and renders a list under your target versions. Run an explicit build-versus-adopt decision afterwards, with this package as the adopt candidate and native framework table tooling as the build candidate.
- How do I avoid lock-in if I adopt povs/lister-twig-bundle?
- Fork it into an internal namespace immediately, add CI, and pin a version you control. Wrap it behind an internal list-service interface so the rendering layer can be swapped without touching feature code. The MIT license makes the fork clean, and for a Symfony application already running ListerBundle the routine require, bundle registration, and configuration step keeps the initial effort low.