Avlist Bundle Laravel Package

Getting Started

• Confirm you actually need this. pdfloresjdav/avlist-bundle is a Symfony bundle, not a Laravel package. If you're in a Laravel app, expect to wire it manually (or skip it). If you're in Symfony, proceed.
• Install: composer require pdfloresjdav/avlist-bundle. With 0 stars / 0 dependents, pin an exact version ("pdfloresjdav/avlist-bundle": "x.y.z") rather than a floating constraint.
• Register the bundle: add it to config/bundles.php (Symfony Flex should do this automatically). Without registration, nothing else works.
• Look here first, in this order:
  1. README.md — likely sparse; treat it as a starting hint, not truth.
  2. src/ — the actual list service/manager class and any Twig extension.
  3. DependencyInjection/Configuration.php — the real config schema; this is your source of truth.
  4. Resources/config/services.yaml (or *.xml) — what IDs are public vs. autowired.
• First use case: wire the bundle's list service into a controller, feed it an array/query result, and render it (via a Twig function if one is shipped). Start with the smallest possible page — one list, one template — before layering filtering or pagination.

Implementation Patterns

• Config-driven definitions. Symfony bundles of this shape usually expose a config/packages/av_list.yaml tree (root key likely av_list). Define your lists/columns there and let the bundle build services. Read Configuration.php before writing YAML — guessing key names is the #1 time sink.
• Service injection over static calls. Inject the bundle's manager/service into controllers and services by constructor. Check whether its services are public: false (default) — you may need to alias or bind the concrete class.
• Template integration. If a Twig extension is registered, prefer passing a list object into the template and calling the bundle's render/list function, rather than reconstructing HTML in the controller.
• Repository/service composition. Typical day-to-day flow: repository → DTO/array → bundle list service (applies columns/sorting/filtering) → Twig render. Keep the bundle at the presentation boundary; don't let it drive query logic.
• Events / listeners. If the bundle dispatches events around list building, hook there for per-request customization rather than overriding services or editing vendor code.
• Testing pattern. Instantiate the list service directly in a unit test with a hand-built array; reserve kernel/browser tests for the Twig rendering layer.

Gotchas and Tips

• No community validation. Zero stars and zero dependents means no real-world bug reports, no Stack Overflow answers, and no security review. Read every file under src/ before trusting it in production; vendor it or fork it if it's load-bearing.
• Symfony/Laravel mismatch. As a Laravel developer, do not assume Laravel conventions. No service providers, no facades — you'd need a custom bridge. Often cheaper to reimplement a 12-line list helper than to integrate a Symfony bundle.
• Config key guesses fail silently. Symfony config trees ignore unknown keys unless ->ignoreExtraKeys(false). Run bin/console debug:config av_list (replace with the real root key) to see merged values.
• Autowiring surprises. Confirm the manager's service ID and whether it's autowirable: bin/console debug:container --show-private | grep -i av. Alias it explicitly in services.yaml (AvList\Manager: '@av_list.manager') if autowiring fails.
• Version drift. Check composer.json require for Symfony version ranges — an unsupported range will install but break at runtime. Pair with your Symfony minor version.
• Twig extension not registered? If the bundle is registered but the function errors, verify the twig.extension tag or the extension's service definition in the bundle's services.yaml; a mis-tagged extension is invisible until template render time.
• Debugging checklist: debug:router, debug:twig, debug:container, then the bundle's own tests/fixtures. With no docs, the bundle's test suite (if any) is the closest thing to usage examples.
• Escape hatch. Because it's unmaintained, plan for removal: isolate all bundle calls behind one adapter class in your app so you can swap it out without touching templates and controllers.