Resource Bundle Laravel Package

Product Decisions This Supports

• Stack-fit gate (read this first). Despite the "Laravel/PHP package" framing, this is a Symfony bundle built on Doctrine ObjectManager/ObjectRepository. If the product is on Laravel/Eloquent, this is a non-starter and the decision is closed. If we are on Symfony + Doctrine (ORM or ODM), it is a legitimate candidate.
• Build vs. buy for the CRUD layer. The alternative is hand-rolling a base controller/resource-registry/routing convention across our resources — realistically 2–4 senior-engineer sprints plus permanent maintenance. This is a composer require with MIT licensing and a Sylius-maintained codebase. The break-even point is roughly 8–10 resources with near-identical CRUD; below that, our own thin abstraction is cheaper.
• Architecture decision: one resource, many presentations. The core value proposition is eliminating duplicated "backend" vs "frontend" vs "API" controllers for the same entity, with sorting/filtering/lookup-by-id-or-slug handled declaratively. This directly supports a roadmap where we expose the same domain objects through admin HTML, a JSON API, and/or a storefront without triplicating controller code.
• Scope decision: not an admin generator. This is explicitly not EasyAdmin/Sonata. It won't generate forms, filters, or grids for us. That means a roadmap choice: adopt this as the foundation and build/pair our own form and grid tooling, or pick a generator for back-office and use this only where multi-surface reuse matters.
• Framework and persistence commitment. Adoption locks us into Symfony routing/DI conventions and Doctrine. It is persistence-agnostic only within Doctrine (ORM/ODM), not across persistence layers. Treat this as a platform decision, not a library decision.
• Vendor and longevity assessment. MIT, commercially backed by Sylius (the eCommerce product ships on it), with an active 1.10 maintenance line and an in-progress 1.11 feature line. That is a healthier signal than the raw community numbers suggest.
• Use cases that fit well: multi-tenant SaaS with many similar CRUD resources; headless/commerce-adjacent products; internal tooling where the same record type is viewed by ops, customers, and integrations; any product where "list with filters + sort + paginate + fetch by slug" is a repeated pattern.
• Metrics caveat for the decision record. 234 stars and 0 listed dependents are almost certainly artifacts of the bundle being consumed via the Sylius monorepo rather than directly. Do not let either number drive the call — evaluate the code, the changelog cadence, and the docs instead.

When to Consider This Package

Adopt when:

• The stack is Symfony (maintained versions — PHP 8.0 and unmaintained Symfony lines were dropped in 1.11) with Doctrine ORM or an ODM.
• We have a meaningful number of resources (≥8) sharing the same CRUD shape and the same filtering/sorting/pagination needs.
• The same resource must be rendered through more than one surface (admin, API, storefront) — this is where the payoff is largest.
• We want convention-driven resource metadata (attributes for resource class, driver, operations) rather than hand-wired controllers per action.
• The team is willing to own the presentation layer (forms, grids, templates) on top of it.
• We are already in, or comfortable entering, the Sylius ecosystem (including its state-machine and grid integrations).

Look elsewhere when:

• Laravel / Eloquent. Wrong framework, wrong persistence abstraction. Do not spend evaluation time here.
• We need an admin generator. If the goal is "back-office CRUD in a week," EasyAdmin or Sonata delivers that; this package explicitly does not and will feel like a detour.
• Resource count is small or shapes are heterogeneous. The abstraction cost exceeds the duplication it removes.
• API-first with OpenAPI/hypermedia/JSON-LD requirements. API Platform is the stronger, more standards-complete choice; this bundle is a controller foundation, not an API specification engine.
• Heavy per-resource domain logic in controllers. If each resource's write path is genuinely bespoke (approvals, multi-step orchestration, external side effects), the generic operation model becomes friction.
• We need long-term cross-minor-version API stability. v1.11 ships an experimental routing system, and the 1.11.0 line contains extensive namespace relocations ("Move namespaces on…" across Grid, Factory, Metadata, Twig, Context, Storage, Exceptions). Pin a version deliberately; do not float.
• We intend to contribute upstream. There is no main/master; PRs must target a specific minor-version branch (1.10, 1.11). That is a real governance constraint on our ability to land fixes on our own schedule.
• Persistence is non-Doctrine (raw DBAL, Elasticsearch-primary, legacy gateway). The ObjectManager abstraction won't help.

Recommended posture if we proceed: pin to 1.10.* for production stability, evaluate 1.11 in a spike, and treat the routing layer as experimental until it stabilizes.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a free, MIT-licensed Symfony component from Sylius that removes duplicated CRUD controller code. Instead of writing the same list/create/read/update/delete logic three times for admin, API, and storefront, we define a resource once and expose it everywhere with built-in filtering, sorting, and pagination. The business case is delivery speed on repetitive resource work and lower long-term maintenance surface. The cost is a framework-level commitment to Symfony and Doctrine plus a ramp-up period — no license fee, but real engineering time. Vendor risk is moderate-low: it is maintained by a commercial open-source company that ships it in its own product, though standalone community signals are thin and the newest feature line is still stabilizing.

For engineering (the honest version):

• What we get: resource metadata via attributes, Doctrine ObjectManager/ObjectRepository-based persistence, format-agnostic controllers, declarative operations and routing, request→data→view processing pipeline, grid/state-machine hooks, Pagerfanta pagination, JMS serializer support.
• What we do not get: forms, filters, grids, or admin UI. We build or integrate those.
• What we must own: version pinning, an upgrade plan for the 1.11 namespace migrations, and a decision on the experimental routing system.
• Risk register: upstream PRs are minor-branch-scoped (no main); PHP 8.0 and older Symfony lines are unsupported; the abstraction is Doctrine-only, so it will not save us if persistence changes.
• Recommendation: timebox a two-day spike on one real resource, measure lines-of-controller-code removed, and decide on that evidence rather than on stars or dependents.