- What is remg/generator-bundle?
- remg/generator-bundle is a Symfony 3 bundle that provides code-generation tools for scaffolding repetitive backend code from existing Doctrine models. It is intended to reduce boilerplate in Symfony applications, not Laravel applications. Its value is in command structure and templates rather than runtime behavior.
- Can I install remg/generator-bundle in a Laravel application?
- No. The package depends on the Symfony kernel, the Symfony DI container, SensioGeneratorBundle, Doctrine ORM metadata, and Twig, so Composer will not resolve it alongside a Laravel application. Treat it as not a direct fit for a Laravel stack. There is effectively zero drop-in integration path.
- Does remg/generator-bundle support Laravel 10 or Laravel 11?
- No. It is a Symfony 3 bundle, and Symfony 3.4 reached end of life in November 2021. Its PHP constraint almost certainly caps below PHP 8.x, which conflicts with modern Laravel requirements. It will not install or run in Laravel 10 or Laravel 11.
- What Laravel tools should I use instead of remg/generator-bundle for CRUD scaffolding?
- Use Laravel-native options such as artisan make:* commands with published stubs, Blueprint for schema-first generation, InfyOm generators, or internal project stubs. These are maintained for current Laravel versions and avoid the Symfony 3 dependency chain. For most teams, standardizing on artisan stubs captures the same boilerplate-reduction benefit.
- Is remg/generator-bundle still maintained?
- No. The repository is archived with no maintainer, no security response process, and no compatibility fixes. It has 0 dependents and 25 stars, so there is no downstream community absorbing edge cases. This is a terminal state, not a temporary pause.
- What PHP and Symfony versions does remg/generator-bundle require?
- It is built for Symfony 3 and its PHP constraint is from the PHP 5.6 or 7.1 era. Symfony 3.4 support ended in November 2021, and the package will conflict with modern Symfony and Laravel dependency graphs. Any trial should run in a disposable container with a pinned legacy PHP runtime.
- Can I use remg/generator-bundle as a reference for building my own Laravel generator?
- Yes, that is the most practical use. Read its command structure, template organization, and metadata-driven field inference, then apply those patterns to a Laravel-native generator. The durable value is in the design ideas, not the shipped Symfony code.
- Should I fork remg/generator-bundle to make it Laravel-compatible?
- Only if you have a named owner and a roadmap that native alternatives cannot serve. Making it work with Laravel would require substantial PHP 8 and Doctrine API work, effectively a rewrite. Prefer building on Laravel-native tooling or internal stubs instead.
- What are the risks of committing code generated by remg/generator-bundle?
- Generated code becomes your code the moment it is committed. Templates from a 2016-era Symfony bundle may encode outdated patterns for input handling, auth stubs, and ORM usage that you would not write today. Review and rewrite generated output before merging rather than treating it as production-ready.
- How should I evaluate remg/generator-bundle safely?
- Run a short sandbox spike in a disposable container with a pinned legacy PHP runtime and a throwaway schema. Assess output quality, template readability, and how much hand-editing the result requires. Do not add it to your application composer.json; keep any experiment in an isolated tooling repository.