Weave Code
Report Bundle Laravel Package
sylius/report-bundle
Sylius ReportBundle adds configurable reporting to Sylius stores, with data fetchers, renderers, and admin integration for building and viewing reports. It helps manage report definitions and display store metrics.
[READ-ONLY] Subtree split of Sylius reports system!
Frequently asked questions about Report Bundle
- Is sylius/report-bundle a Laravel package?
- No. It is a Symfony bundle built on Sylius conventions such as dependency injection compiler passes, tagged services, Doctrine ORM mapping, Twig rendering, and Sylius admin and grid abstractions. Laravel uses service providers, Eloquent, Blade, and policies, so the code does not fit a Laravel application without a rewrite or an isolated Symfony runtime.
- Can I install sylius/report-bundle with Composer in a Laravel app?
- Composer may install it, but installation is not integration. The package is an archived, read-only subtree split of Sylius, and its Symfony and Sylius constraints can conflict with modern PHP and Laravel dependency graphs. Treat any install as a short spike only, not a production path.
- What Laravel versions does sylius/report-bundle support?
- None. It does not declare Laravel support because it is a Symfony and Sylius bundle, not a Laravel package. Compatibility is tied to historical Sylius and Symfony versions, and the archived status means no updates for current PHP, Symfony, or Laravel releases.
- What does sylius/report-bundle actually do?
- It adds configurable reporting to Sylius stores. A report definition binds a data fetcher alias and a renderer alias, with implementations resolved by service tags, plus admin integration for building and viewing reports. Its shipped report types cover common store metrics such as orders and sales, customers, and product performance.
- How does report configuration work in Sylius ReportBundle?
- Reports are configured through Sylius and Symfony conventions: report definition entities, data fetcher and renderer aliases, tagged services, and admin grid and resource integration. Configuration lives in Symfony service definitions and bundle config, not Laravel config files. That vocabulary is useful as a design reference but is not directly reusable in Laravel.
- Can I use sylius/report-bundle with Eloquent instead of Doctrine?
- No, not without a rewrite. The bundle is built around Doctrine ORM mapping and Sylius resource abstractions, while Laravel reporting would normally use Eloquent or the query builder against a read replica. You could port the concept of a report definition with pluggable fetcher and renderer interfaces, but not the implementation.
- Is sylius/report-bundle maintained and safe for production?
- It is archived and read-only, so there is no security response, no PHP or Symfony compatibility work, and no issue triage. Because it is a generated subtree split, fixes belong upstream in Sylius/Sylius, which you do not control. For production, that means any patch becomes an internal fork, which is a high and asymmetric risk.
- What should I do if sylius/report-bundle is already in composer.lock?
- Treat it as an unmaintained admin surface with no upstream patch path. Open a removal or replacement ticket and confirm whether reporting is actually used, who consumes it, and what data access it exposes. Then migrate the reporting model to a Laravel-native module or a supported commercial tool rather than trying to modernize the bundle.
- What are alternatives to sylius/report-bundle for Laravel reporting?
- Build a Laravel-native reporting contract covering report definitions, filters and parameters, renderer and exporter interfaces, permissions, scheduling, caching, and audit trails. Implement it with queued jobs, Eloquent or query builder reads from a replica or warehouse, Blade or API resources, policies and gates, and the scheduler. Alternatively, evaluate a licensed BI or reporting tool if analytical or customer-facing reporting is the real requirement.
- Can I reuse sylius/report-bundle tests or code as a reference?
- The subtree split is read-only and tests live upstream in Sylius/Sylius, so there is no Laravel-oriented test suite to reuse. You can still read the upstream code and shipped report types as a domain reference for report definitions, data sources, filters, renderers, exporters, and admin grids. Treat that material as a checklist for your own Laravel module, not as runnable assets.
Weaver
How can I help you explore Laravel packages today?