Resource Bundle Laravel Package

Technical Evaluation

What this package actually is sylius/resource-bundle is a Symfony bundle, not a Laravel package. It provides format-agnostic CRUD controllers, resource metadata (via the AsResource PHP attribute), routing factories, and basic sorting/filtering/pagination on top of Doctrine's ObjectManager / ObjectRepository interfaces. It explicitly is not an admin generator — it does not generate forms, grids, or filters. It is the CRUD substrate that Sylius itself is built on.

Architecture fit

• Against a Laravel monolith: poor fit. The bundle is wired through Symfony's HttpKernel, DependencyInjection, Routing, EventDispatcher, Form, and DoctrineBundle. There is no Laravel service provider, no config/resource.php publishable config, no facade, no Eloquent integration.
• Doctrine vs. Eloquent is the hard wall. It depends on Doctrine Common Persistence contracts. Laravel's default ORM (Eloquent/ActiveRecord) does not implement ObjectManager/ObjectRepository. Bridging requires standing up Doctrine alongside Eloquent in the same app — dual ORMs, duplicated migrations, and two unit-of-work lifecycles.
• Where it does fit: a Symfony application, or a separate Symfony service exposing CRUD endpoints that a Laravel app consumes over HTTP. That is the only realistic path.

Integration feasibility

• Direct in-process adoption inside Laravel: not feasible without abandoning Laravel's framework conventions.
• Bounded-context Symfony CRUD service: feasible, but the cost is "stand up and operate a second framework runtime" to save controller boilerplate that Laravel already reduces via resource controllers and API Resources.
• The honest TPM read: the opportunity score (74.2) reflects the package's quality in its own ecosystem, not transferability to ours.

Technical risk

Key questions to answer before committing

1. Is any part of our roadmap a Symfony service, or is "Laravel/PHP" shorthand for a polyglot PHP estate? If Laravel-only, this is a no-go.
2. Do we need multi-backend persistence (ORM and ODM)? That is the bundle's core differentiator; if not, we are paying migration cost for a benefit we don't use.
3. Who owns the Symfony runtime, deployment pipeline, and security patching for a second framework?
4. Is pinning to the 1.10 bugfix branch acceptable if we need stability, given 1.11 introduced namespace relocations?
5. What is the actual LOC/boilerplate saving versus Laravel resource controllers + API Resources? If it's under ~20%, the ROI is negative.
6. Does the team have Symfony + Doctrine fluency, or is this a multi-week ramp we haven't budgeted?

Integration Approach

Stack fit

• Target runtime: PHP 8.1+ (1.11 dropped PHP 8.0 and unmaintained Symfony versions), Symfony 5.4/6.x/7.x, Doctrine ORM or ODM, optional JMS Serializer (^5.0 allowed), Pagerfanta (^4.0 allowed), Twig, Symfony Workflow for state machines.
• Our stack: Laravel + Eloquent. Overlap is limited to PHP and Composer. There is no supported coexistence mode.
• Recommendation: classify this as a "Symfony-service-only" dependency. Do not add it to the Laravel composer.json.

Migration path (if a Symfony service is approved)

1. Spike/POC in a throwaway Symfony app: one resource, attribute-based routing, JSON responses, pagination, one filter. Timebox 1–2 weeks.
2. Define the bounded context. Pick exactly one low-risk entity (e.g., reference/catalog data) — not a core transactional domain.
3. Own the data contract. The Symfony service owns its schema and migrations. The Laravel app consumes an HTTP API; do not point both frameworks at the same tables.
4. Expose JSON, either through the bundle's controllers directly or behind API Platform if we need OpenAPI/hydration guarantees.
5. Instrument the saving: measure controller/metadata boilerplate removed versus new operational surface (second deploy target, second CI, second auth layer).
6. Decide at the end of step 5: expand, hold, or retire.

Compatibility

• Pin versions explicitly. Prefer 1.10.* if we need API stability; 1.11 carries namespace relocations that will break copied examples and any internal extensions.
• Verify JMS Serializer, Pagerfanta, and Doctrine Collections versions against the Laravel app's shared transitive graph if both live in one monorepo.
• Symfony major upgrades are the primary compatibility driver; budget a review each Symfony release cycle.

Sequencing

• Phase 0 (1 week): framework-fit decision memo. If Laravel-only, close the evaluation and document the alternative (Laravel resource controllers, API Resources, and a query-filter package) — that covers ~80% of the value at zero new dependency.
• Phase 1 (1–2 weeks): POC only if a Symfony service exists or is already planned.
• Phase 2 (4–6 weeks): single bounded-context CRUD service, one entity, with observability and deployment.
• Phase 3: go/no-go review with measured boilerplate savings and operational cost delta.

Operational Impact

Maintenance

• MIT-licensed, Sylius-backed, actively released (most recent 2026-06-22), with README, changelog, and releases present — maturity signals are adequate for a library of this scope.
• Maintenance burden shifts onto us: a second framework runtime, its security patching, its Doctrine migrations, and its upgrade cadence. The bundle itself is small; the surrounding Symfony app is not.
• The 1.11 namespace reorganization means our own extensions (custom routing factories, operation handlers, event subscribers) will need periodic mechanical updates.

Support

• Community support via GitHub issues only. No SLA, no vendor contract tied to this bundle as a standalone product.
• Documentation lives on stack.sylius.com/resource and is oriented to Symfony developers; expect to translate patterns ourselves.
• Bus factor is real: releases are concentrated in a small set of Sylius maintainers. Acceptable for a foundation library, not for anything on the critical path without a fallback plan.

Scaling

• The controllers are stateless and horizontally scalable; no built-in caching layer, so read-path caching is our responsibility.
• Pagination via Pagerfanta is fine; a grid-limit bug was fixed in 1.11.2, so pin at or above that if grids are used.
• Grid and filter queries are basic and can produce N+1 patterns on richer resources — plan query review and indexing per resource.
• Sorting/filtering driven by request parameters must be allow-listed server-side; this is our guardrail to add, not the bundle's.

Failure modes

• Missing or malformed resource metadata → container compilation / routing failures at deploy time (fails fast, which is good).
• Doctrine mapping drift between the service and any shared read models → silent data inconsistency.
• Serializer version conflicts (JMS) in a shared dependency graph → runtime 500s on response building.
• Symfony minor upgrades breaking event listeners and subscribers — precedent exists (translatable listener fix for Symfony 5 in 1.11.1).
• State machine misconfiguration per resource causing invalid transitions rather than clean errors.
• Filter/sort injection if request-driven criteria are not whitelisted.

Ramp-up

• A Laravel-only team should budget 2–4 weeks to become productive with Symfony + Doctrine conventions (DI compilation, attribute-based config, unit of work, mapping).
• Add 1–2 weeks for the resource metadata, operation, and routing-factory model specifically.
• Assign a named owner for the Symfony runtime. Ongoing cost is continuous, not one-time: one engineer partially allocated per Symfony/Doctrine release cycle.

TPM recommendation Default position: do not adopt for a Laravel stack. The framework mismatch, dual-ORM tax, and the fact that it is explicitly not an admin generator make the value proposition negative for us. Revisit only behind a funded decision to run a Symfony bounded-context service, and then treat sylius/resource-bundle as an internal implementation detail of that service — pinned, owned, and measured — rather than a package the Laravel application depends on.