Resource Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for CRUD scaffolding. The core bet is whether to hand-write index/show/create/update/delete controllers per entity or adopt a config-driven foundation. This package makes the "buy" side cheap: one resource definition (class + driver) yields routing, controllers, filtering, sorting, and pagination — so the decision shifts from "how many controllers do we write?" to "how much do we customize?"
• Single code path for HTML and API surfaces. The README explicitly targets the "separate backend/frontend controllers" duplication problem. That directly supports a roadmap decision to ship a JSON API alongside server-rendered pages for the same resources without budgeting two implementations. If you're planning an API for a mobile app or partner integrations, this is the strongest product argument for adoption.
• Roadmap scoping for internal tooling. Be precise: this is not an admin generator. It won't generate forms, filters, or grids. That means it supports the decision "we will build a lean, custom back-office on a predictable foundation," but not the decision "we need a working admin panel by end of quarter." Treat it as infrastructure, not a feature delivery accelerator.
• Multi-persistence flexibility as a hedge. The Doctrine ObjectManager/ObjectRepository abstraction means the resource layer isn't welded to ORM — relevant if you're weighing ODM/Document stores for a subset of domains. Modest decision value, but it de-risks a later storage choice.
• Deprioritizing bespoke filtering/sorting work. Built-in filtering, sorting, and lookup-by-id/slug means "advanced list filtering" can stay in the backlog rather than becoming a per-entity engineering tax.
• Ecosystem alignment. If Sylius is on your radar (or already in the stack), adopting the resource layer is a low-regret step toward a compatible architecture.

Caveats that should temper the above: the score (47.9) and adoption signals are middling — 234 stars and 0 listed dependents, despite this being a subtree split of a package Sylius itself depends on. The opportunity score (73.7) is the more interesting number: real unmet need, thin standalone traction. Fund a spike, not a mandate.

When to Consider This Package

Adopt when:

• You are on Symfony with Doctrine ORM/ODM. This is a Symfony bundle — despite the framing as a general PHP package, it will not drop into Laravel, and trying to port it costs more than it saves. If your stack is Laravel, stop here and evaluate Laravel resource/nova-style equivalents.
• You have many resources sharing the same CRUD shape (the "20 entities, 20 near-identical controllers" smell). Value scales roughly linearly with entity count.
• You need the same resource rendered in multiple formats (HTML + JSON + maybe CSV), which is where the format-agnostic controller design earns its keep.
• You want a foundation to build on, with a team comfortable owning the forms, grids, and templates on top.
• You value MIT licensing and no vendor cost — relevant if procurement cycles are a bottleneck.

Look elsewhere when:

• You need a finished back-office fast. Use EasyAdmin, SonataAdmin, or Sylius' full admin stack. Choosing this and expecting forms and grids is the single most likely way to burn a sprint.
• Your entity count is small (under ~5). The learning curve, config indirection, and debugging overhead likely exceed the boilerplate saved.
• Your team is not deep in Symfony conventions. The bundle leans on DI, attributes/annotations, expression language, and Doctrine Common interfaces. Onboarding cost is real and rarely budgeted.
• You require a stable, slow-moving API. The 1.11 alpha changelog is dominated by namespace relocations ("Move some namespaces on..."), and the repo has no main/master — PRs target minor-version branches. That's a maintenance model that demands attention each upgrade.
• Bus factor is a hard constraint. Development is concentrated around Sylius maintainers. Fine for a bet hedged by MIT + forkability; not fine if you need contractual support.

Cheap validation step before committing: timebox a spike on your two most complex resources and measure the delta versus your current controller boilerplate. If the win isn't visible there, it won't be visible anywhere.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a free, open-source (MIT) Symfony component that removes duplicated CRUD code — the repetitive "list, view, create, edit, delete" plumbing we rewrite for every entity. It lets one definition serve both our web pages and any future API, which is the strategic upside: we don't pay twice for the same resource. It is infrastructure, not a finished admin product — it won't replace the back-office work itself, and it carries a modest learning and maintenance cost. Recommendation is a short, bounded technical spike on two existing resources to quantify the savings before any broader commitment. Cost of trying is low; cost of adopting blind is a wasted sprint.

For engineering leads: The value proposition is concrete — format-agnostic controllers built on Doctrine ObjectManager/ObjectRepository, with filtering, sorting, and multi-format responses driven from a single resource configuration. It is explicitly not an admin generator; we own forms, grids, and templates. Fit requires Symfony + Doctrine and a team comfortable with the bundle's conventions. Risks to price in: namespace churn between minor versions (see the 1.11 alpha series), a branch-per-minor-version contribution model with no main, and thin standalone adoption (234 stars, 0 listed dependents) meaning we should expect to read source rather than rely on community answers. MIT license and forkability bound the downside. Ask: two-day spike, two representative resources, measure controller LOC removed and hours to first working index/show/create/update/delete in both HTML and JSON.