Report Bundle Laravel Package

Getting Started

First, the framing: despite the name, gepur-it/report-bundle is a Symfony bundle, not a Laravel package. If you're working in a Laravel codebase you cannot composer require it and expect it to boot — it registers services through Symfony's Bundle/Extension/CompilerPass machinery and expects a Symfony kernel. Realistic options are (a) run it inside a small Symfony service/console app that talks to the same database, or (b) treat it as reference source and port the report-building logic into Laravel services. Decide this before writing any code; it changes the whole integration.

For a Symfony app:

1. composer require gepur-it/report-bundle — check what Symfony and PHP constraints composer.json declares. Last tagged release is May 2021, so expect symfony/* ^4.4 || ^5.x style constraints; on Symfony 6/7 you will likely need --ignore-platform-reqs-style workarounds or a fork.
2. Register the bundle in config/bundles.php.
3. Read DependencyInjection/Configuration.php first. That tree is the authoritative list of config keys (report storage path, DB connection, renderer selection, etc.). Add a minimal config/packages/<alias>.yaml matching the alias returned by Configuration::getAlias().
4. Skim Resources/config/services.xml|yaml to learn the public service IDs — the generator/report-manager service you'll inject into a controller or command.
5. Read the README examples and any Tests/ fixtures; with 2 stars and no docs site, the tests are effectively the documentation.

First use case: pick the simplest end-to-end path — one report definition, one output format, triggered from a bin/console command rather than a web controller. Get report -> query -> render -> file on disk working before touching filters, scheduling, or UI.

Implementation Patterns

• Report-as-service definitions. Expect report classes to be registered with a DI tag and collected by a compiler pass. Follow that convention rather than instantiating reports by hand — it's how the bundle discovers available reports and how any report-listing UI will work. If the tag name isn't obvious, grep for addTag( and findTaggedServiceIds in src/.
• Thin controller / fat command. Put generation behind a console command (and, if needed, a queued message) and keep the HTTP layer to "accept parameters, dispatch, return the artifact." Report generation is slow and memory-hungry; never do it synchronously in a request if the dataset is non-trivial.
• Parameter objects over arrays. Whatever the bundle accepts as report arguments (date ranges, filters, tenant/CRM IDs), wrap them in a small immutable DTO in your code and validate before handing off. This is the seam that keeps you portable if you later replace the bundle.
• Separate the three stages explicitly: fetch (Doctrine/DBAL query), transform (aggregation, formatting, currency/locale), render (the bundle's output writer). When a number is wrong, you want to know which stage without bisecting the bundle.
• Scheduling. Use Symfony Scheduler or cron to trigger recurring CRM reports, write to a versioned filename (reports/{name}/{Y-m-d}/{id}.{ext}), and keep a retention policy outside the bundle.
• Tenancy/security. If this is CRM reporting, every query is filtered by customer/owner scope. Enforce that in your data-access layer, not in the report template, and add a test that asserts a report for tenant A never contains tenant B rows.
• Testing. Build a fixture dataset (fixtures or an in-memory SQLite schema), then golden-file the rendered output where the format allows, or assert on the extracted rows for PDF/XLSX where it doesn't.

Gotchas and Tips

• The big one: it's abandoned-ish and essentially unproven. 2 stars, 0 dependents, last release 2021-05-19 means no community, no Stack Overflow answers, no security patches, and no one else has hit your bug before you. Budget for reading the source yourself, and consider vendoring/forking it into your repo so you can patch it. If you're starting greenfield, price out the alternative honestly: Doctrine DBAL + PhpSpreadsheet / Dompdf is usually a few hundred lines and zero integration risk.
• Laravel mismatch. No service provider, no facade, no config/report.php merge. Symfony's Reference, tagged iterators, and %parameter% resolution have no Laravel equivalent. A "port" means rewriting the orchestration, keeping only the query/formatting ideas.
• Version drift. A 2021 bundle will trip on PHP 8.1+ deprecations (dynamic properties, missing return types on Bundle subclasses) and Symfony 6's stricter container (private services by default, removed TreeBuilder behaviours). Run bin/console lint:container and debug:container early; if it won't compile, stop and reassess rather than fighting it.
• Config alias mismatch is the classic first failure: the YAML root key must exactly equal Configuration::getAlias(). Wrong key = silently ignored config, then a confusing "service not found" or missing-path error at runtime.
• Debug order: debug:container <service> to confirm registration → debug:container --tag=<tag> to confirm your report was collected → debug:event-dispatcher if generation is event-driven. Most "my report doesn't show up" issues are a missing tag or a service that isn't public/autowired in the right namespace.
• Extension points to look for: custom renderers/writers registered by tag, and overridable Twig templates under Resources/views (override by placing same-path files in templates/bundles/<BundleName>/). Both are cheap ways to adapt output without forking.
• Memory and timeouts. CRM reports over large tables blow past memory_limit on PDF rendering especially. Stream/chunk at the query level, raise limits only in the CLI command, and set an explicit statement timeout on the DB connection.
• Determinism. Pin locale, timezone, and currency formatting in config so the same parameters produce byte-identical output; otherwise diffing generated reports becomes impossible and every "why did the numbers change" investigation is a dead end.