- Is stanlemon/rest-bundle compatible with Laravel?
- No. Despite appearing in Laravel package searches, stanlemon/rest-bundle is a Symfony bundle that hooks into Symfony's bundle system, DI container compiler passes, kernel event listeners, and Doctrine ORM entity metadata. None of those extension points exist in Laravel, where routing is service-provider driven and persistence is Eloquent rather than Doctrine. This is a paradigm mismatch, not an adapter problem, so there is no drop-in path.
- How do I install stanlemon/rest-bundle in a Laravel project?
- You cannot meaningfully install it. Composer will resolve the package, but there is no service provider to register, no bundle registration mechanism, and no Doctrine metadata pipeline for it to read. In Laravel you would instead use Route::apiResource, API Resources, and Form Requests to build the same thin resource layer natively.
- What does stanlemon/rest-bundle actually do?
- It is a Symfony bundle that auto-exposes REST endpoints for Doctrine entities, using annotation-driven route registration, serialization support, and reusable controller utilities. The goal is to reduce boilerplate so PHP developers can expose resources quickly and consistently. It relies entirely on Symfony and Doctrine internals to do that.
- What are the Laravel alternatives to stanlemon/rest-bundle?
- Laravel covers the same value proposition natively with Route::apiResource for endpoints, API Resources for serialization, Form Requests for validation, and query-builder packages for filtering, pagination, and relationship expansion. On the Symfony side, API Platform is the actively maintained, OpenAPI-first equivalent. Choosing a decade-stale auto-CRUD bundle over either option is a false economy.
- Is stanlemon/rest-bundle still maintained and safe for production?
- No. The project is archived upstream, with no security patches, no PHP 8.x or 9 compatibility work, and no framework version bumps. With only around 121 stars, documentation is thin and there is effectively no community answer pool. Any CVE in its dependency chain becomes your incident, so it is not a safe production dependency.
- Can I run a Symfony app using this bundle alongside a Laravel app?
- It is technically possible with a shared database and a reverse proxy, but you inherit two frameworks, two DI containers, two auth and session models, and two deployment topologies. The operational cost dwarfs any scaffolding benefit you get from the bundle. Treat this only as a temporary coexistence pattern during a migration, never as a target architecture.
- How do I migrate away from stanlemon/rest-bundle to Laravel?
- Use a strangler fig approach: inventory every route the bundle emits and the exact JSON shape it returns today, then freeze that shape as an OpenAPI spec so the contract, not the bundle, is the source of truth. Stand up the Laravel replacement behind a path prefix and cut over route by route behind a gateway or reverse proxy with per-route feature flags. Dual-run with traffic mirroring and response-diff assertions until the new endpoints match exactly.
- Does auto-generated CRUD from Doctrine entities leak data?
- Yes, this is the biggest risk. Auto-generated endpoints frequently over-expose model fields and relationship graphs by default, which creates a data-leak and denial-of-service surface in a way hand-written controllers do not. You must explicitly define the serialized shape rather than trusting framework defaults, and that effort is precisely what a thin hand-rolled Laravel layer gives you.
- How much effort is it to rebuild this functionality in Laravel?
- For a small, well-scoped surface it is realistically 2 to 4 engineer-weeks using Route::apiResource, API Resources, Form Requests, and a small config map of exposed entities. Port cost rises materially if the team is not Symfony-fluent enough to read the bundle source as documentation. Route-generation sprawl is the main scaling failure mode, so scope the entity count and relationship depth first.
- Is stanlemon/rest-bundle MIT licensed and can I fork it?
- Yes, the MIT license is clean, permissive, and the one unambiguous positive about the package. You can fork it legally, but repository metadata is unknown, so there is no resolvable canonical source and provenance verification is weak. Treat any distributed artifact as untrusted until hashed and vendored, and define an explicit sunset criterion before committing to maintain a fork indefinitely.