Report Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for reporting. This bundle is the historical answer to "what reporting ships with Sylius." Its archived, read-only state is the finding: the only free option in this lane is dead, so any roadmap item that assumed "reporting comes with the platform" must be re-scoped into an explicit build-or-buy decision with its own budget line.
• Requirements checklist for a reporting epic. Its report definitions (sales/order, customer, product performance, and similar admin reports) are a free, battle-tested list of table-stakes reports your users will ask for. Use it to beat the baseline rather than rediscover it in discovery.
• Architecture vocabulary for an in-house module. The abstraction it encodes — report definition, pluggable data fetcher, pluggable renderer, grid/admin surface — is a sound skeleton to spec your Laravel-native reporting service against. Mine it for the domain model and edge cases; do not inherit the code.
• Technical-debt and vendor audit input. If sylius/report-bundle shows up in an existing composer.lock, treat it as a flag: an unmaintained admin surface with no upstream patch path. That surfaces a removal-or-replace decision and a small cleanup estimate, not a feature.
• Platform evaluation. If Sylius is on your shortlist, this tells you the native reporting ceiling — and therefore the real cost hidden inside the "we get analytics for free" assumption in a side-by-side comparison.

When to Consider This Package

Consider it — as reference material, not a dependency — when:

• You maintain a legacy Sylius install where it is already present and you need to understand current behavior before removing or replacing it.
• You are evaluating Sylius as a platform and need an accurate, unflattering picture of its built-in reporting.
• You are specifying your own reporting module for a Laravel app and want a reference domain model (report definition → data fetcher → renderer → grid) to borrow.
• You need to confirm the state of a subtree split during a dependency review — i.e., verify this repo is generated output, not a maintained project.

Look elsewhere — decisively — when:

• Any new build. Archived, 6 stars, 0 dependents. No community, no security response, no release cadence.
• You are not on Sylius. It assumes Sylius resources, grids, DI-container tagging, Doctrine, Twig, and admin routing. That does not port cleanly to a Laravel app, and the port cost dwarfs the value of an archived package.
• You need maintained support. It is a read-only subtree split of the Sylius monorepo; issues and PRs here go nowhere, and real fixes must land upstream, which you do not control.
• You need actual analytics. These are ORM-query reports rendered into an admin grid — operational reporting, not analytical infrastructure. It will not serve warehousing, event tracking, self-serve dashboards, multi-tenant isolation, or large data volumes. A low adoption cost here disguises an expensive dead end.
• You need a stable public API. A generated split carries no compatibility promise independent of the monorepo's internals.

How to Pitch It (Stakeholders)

To executives: This is a ten-minute read, not a purchase. Evaluation cost is effectively zero; adoption cost is high because the package is archived and unmaintained. The recommendation is do not adopt. Its value is diagnostic: it shows exactly what Sylius historically offered for reporting and confirms that reporting is now a gap we must fill ourselves. If reporting is on the roadmap, budget it as an explicit build-or-buy decision rather than assuming platform coverage — and if we run a legacy Sylius install, expect a small cleanup item to retire it.

To engineering: Do not composer require this in new Laravel code. It is a [READ-ONLY] subtree split of Sylius/Sylius — patches belong upstream, so we cannot fix anything ourselves, and "archived" means no security response. If it is already in our lockfile, plan an exit and size the reimplementation. If we want the domain model, read it — the fetcher/renderer abstraction and the report-definition contract are the useful ~200 lines — and reimplement that pattern natively on Laravel (service providers, Eloquent/query builder, Blade/API resources, queued generation, explicit access-control policies) rather than inheriting the Symfony/Sylius coupling. Six stars and zero dependents means no community safety net; we would be the only ones on it.