- Is fsi/resource-repository-bundle a Laravel package?
- No. It is a Symfony bundle that ships a Bundle subclass, a dependency-injection extension, Doctrine ORM entity mappings, form types, and Twig helpers, none of which have a native entry point in a Laravel application. There is no Laravel service provider, facade, or config file. If you want the repository pattern it implements, plan to reimplement it with Eloquent and the Laravel cache rather than pulling it in through Composer.
- Can I install fsi/resource-repository-bundle in a Laravel application?
- Composer will install it, but it will not boot, because Laravel does not register Symfony bundles or load their DI extensions. Making it work would require a hand-written service provider plus laravel-doctrine/orm (or equivalent) so the bundle's entity mappings and EntityManager dependencies resolve. That permanently adds Doctrine ORM as a second persistence stack alongside Eloquent, which is hard to justify for a package with such a small surface area.
- What is fsi/resource-repository-bundle used for?
- It wires FSi's Resource Repository library into the Symfony container as injectable services, so CRUD and query logic live in repositories instead of controllers and entities. The repository services provide reusable create, read, update, and delete operations plus filtering, sorting, and pagination for Doctrine ORM collections. It suits teams already on Symfony with Doctrine who want a thin, service-oriented persistence layer they can extend with custom query logic.
- How do I install and configure it in Symfony?
- Install with composer require fsi/resource-repository-bundle and register the bundle in config/bundles.php, or in AppKernel on older Symfony versions. Then define your repository services through the bundle's configuration and inject them into controllers or application services. Because the package tracks Symfony majors rather than Laravel majors, check the composer.json constraints and the README for the exact tag you intend to use before assuming a supported Symfony range or any backward-compatibility policy.
- What are the alternatives to adopting this bundle in a Laravel app?
- Vendor the pattern natively. The domain model is thin: a resource table keyed by a string name with typed value variants such as text, integer, boolean, date, and file, plus a repository exposing get, set, and has with caching on reads. That maps cleanly onto an Eloquent model, a repository class, and a cache decorator, roughly 150 to 300 lines of code you fully own, with no Symfony container bridge and no second persistence stack.
- Is fsi/resource-repository-bundle actively maintained?
- The adoption signal is close to zero, around three GitHub stars and no dependents, so there is no community to surface defects or validate upgrade paths. Release 4.0.3 does confirm that releases are still being cut and it names a fixing contributor, but a single handle on a single pull request is not a stewardship signal. Check the tag history, commit log, and real release dates before treating active maintenance as established.
- Are patch releases of this bundle safe to trust?
- Treat every version, including patch releases, as unverified until you have tested it yourself. Release 4.0.1 introduced a regression that survived 4.0.2 and was only corrected in 4.0.3 through pull request #105, meaning three patch releases were needed to close a self-inflicted bug in a package with no visible downstream testing. Pin exact versions in composer.json and run your own test suite against any upgrade.
- How do filtering, sorting, and pagination work in these repositories?
- The Doctrine ORM backed repositories expose collection queries with reusable filtering, sorting, and pagination, so you avoid hand-writing DQL inside controllers. You extend a base repository, add your own query logic, and inject the resulting service where it is needed. Keep request-specific criteria in your application layer so the repository stays free of HTTP concerns and remains testable in isolation.
- What are the caching and concurrency semantics of the resource repository?
- The caching contract is not clearly documented: it is unclear whether it targets PSR-6, PSR-16, or the Symfony Cache contracts, and whether the cache is local, shared, or both. It is equally unclear whether invalidation happens on write within the same request and how it behaves across multiple application nodes. If you rely on read caching, verify transactional writes and concurrent updates to the same key yourself, or implement the cache decorator in your own code where you control the guarantees.
- How should I test a resource repository in a Laravel application?
- Test an Eloquent-backed reimplementation against a real database, using SQLite in memory or a transaction-wrapped MySQL connection, and cover the cache decorator with the array cache driver. Add cases for the null-versus-default contract on a missing key, since that behaviour is not documented in the original package. If you do adopt the bundle instead, write integration tests that boot a Symfony kernel and exercise the repository services end to end, because there is no downstream CI you can lean on.