Report Bundle Laravel Package

Product Decisions This Supports

• Reporting scope for a Sylius commerce admin — whether sales/order/customer reporting lives inside the admin UI or moves to an external BI layer (Metabase, Looker, warehouse + dbt). This bundle represents the "inside the admin" option in that trade-off.
• Build vs. reuse — whether to reconstruct report definitions and query logic from scratch, port existing report intent into a maintained system, or wire up an off-the-shelf analytics tool.
• Migration sequencing and technical debt inventory — whether this dependency blocks a Symfony/PHP upgrade, and what it costs to retire versus carry.
• Due diligence on an inherited Sylius codebase — what the current reporting feature set actually sits on, and which report types merchandising/ops users already expect.
• v1 scope-cutting — which reports were historically treated as table stakes, and therefore which omissions will generate support tickets.

Metadata caveat for the decision record: this is a READ-ONLY subtree split of the Sylius reports system. The 1 star, 0 dependents, and low score measure the mirror, not the code's historical usage. Do not cite popularity as a quality signal here — cite the 2017 last release and compatibility risk instead. Equally, do not treat it as the supported distribution channel: if you want this feature, you consume it through the Sylius monorepo at a supported version, not this package.

When to Consider This Package

Consider it when:

• You are already on a Sylius version that shipped this bundle and you are maintaining, not adopting — it's in your lockfile and you need to understand it before you remove it.
• You need a reference implementation of report definitions and query patterns to port into a maintained system.
• You're scoping a migration and need to inventory what existing admin reports actually do.

Look elsewhere when:

• It's a new build. Last release July 2017; assume no PHP 8 / modern Symfony compatibility, no security patching, no maintainer response, no CVE coverage.
• You need a support SLA, a vendor to escalate to, or procurement sign-off on a maintained upstream.
• You want the feature as a dependency — use the supported Sylius release or an external BI tool.

Adoption gate if you proceed anyway: frozen lockfile, zero new surface area, a named owner, and a retirement ticket filed the same sprint. No new features built on it.

How to Pitch It (Stakeholders)

For executives: "This is a 2017 mirror of a legacy Sylius reporting feature — effectively abandoned. It is not a platform we should build on. Its only value is as an inventory of what our admin reports used to do, which helps us scope a replacement rather than guess. Recommendation: don't add it; if it's already in the product, budget a migration off it and stop investing in it."

For engineering: "Read-only subtree split, one release in 2017, unmaintained, no upstream channel. Treat it as a reference for report definitions and query shape during migration — port the intent into the chosen platform and delete the dependency. Don't vendor it into new code, don't extend it."

Anticipate the pushback: someone will point at the low star count as proof it's worthless, and someone else will point at Sylius's real usage as proof it's fine. Both are wrong. The argument that wins is the release date and compatibility horizon, not popularity — because the code was genuinely used, just never through this repository.