Generator Bundle Laravel Package

Getting Started

Treat remg/generator-bundle as a legacy Symfony 3 scaffolding tool, not an actively maintained dependency. It is archived, has very low adoption, and should only be introduced into an existing Symfony 3.x application where the cost of replacing it is higher than pinning it.

Minimal setup:

1. Confirm compatibility before installing. Inspect the package's composer.json for PHP and Symfony constraints. Install it only in a Symfony 3.4-era application and pin an exact version:

   composer require --dev remg/generator-bundle:<exact-version>
   

2. Register the bundle in app/AppKernel.php, preferably only in the dev environment:

   if (in_array($this->getEnvironment(), ['dev', 'test'], true)) {
       $bundles[] = new Remg\GeneratorBundle\RemgGeneratorBundle();
   }
   

3. Discover the actual commands. Command names and options vary by release, and documentation is sparse:

   bin/console list | grep -i remg
   bin/console help <command-name>
   

4. Look at the source first. The most reliable documentation is inside the vendor directory:
   • Command/ — available generator commands and options
   • Resources/doc/ — any bundled documentation
   • Resources/skeleton/ — the templates that produce generated code
   • DependencyInjection/Configuration.php — configurable options
5. First useful use case: generate a CRUD controller, form type, and Twig templates for a simple existing Doctrine entity into a dedicated bundle or namespace. Commit the result immediately so you can review and adapt the generated diff.

Do not expect a modern Flex recipe, Symfony 4+ support, or PHP 8 compatibility. The first practical step is often deciding whether the generated output is worth the integration cost versus using Symfony's MakerBundle in a newer application.

Implementation Patterns

The bundle is most useful as a one-shot scaffolder, not as an ongoing code-generation pipeline.

Generate once, then own the code. Generate into a clean working tree, review the diff, commit it, and treat the output as hand-written code afterward. Repeated regeneration tends to fight customizations.

Isolate generated code. Generate into a dedicated namespace such as AppBundle\Admin or a separate bundle. If you need customization, extend or wrap generated classes rather than editing them in place.

Override templates for project conventions. Copy templates from Resources/skeleton/ into the appropriate override location—typically app/Resources/RemgGeneratorBundle/...—and adjust base template inheritance, flash messages, route names, form themes, and controller conventions. This is the main extension point and is usually more maintainable than patching vendor code.

Use a repeatable wrapper workflow. If you generate more than once, wrap the command in a project script that:

• generates into a temporary or clean directory,
• runs PHP-CS-Fixer,
• runs static analysis and tests,
• shows a diff before committing.

Generate after Doctrine mapping is stable. Forms and CRUD templates depend heavily on entity metadata. Associations, nullable fields, embeddables, and custom column types are common sources of broken generated code.

Keep it out of production and CI runtime. Register the bundle only in dev/test. If you keep it long term, add a CI job that installs the exact pinned version on the supported PHP/Symfony combination so you notice environment breakage.

Plan the exit. For new development, use Symfony MakerBundle or hand-maintained stubs. If the legacy app must stay on Symfony 3, fork the bundle under your own vendor namespace, pin it, and document that the generation path is frozen.

Gotchas and Tips

• Archived and abandoned. There will be no fixes for PHP 8, Symfony 4+, Twig upgrades, or security issues in transitive dependencies. Use only in a legacy Symfony 3 application, as a dev dependency, pinned exactly.
• Sparse documentation and low adoption. With 25 stars and zero dependents, expect version drift and incomplete docs. Read Command/, Resources/skeleton/, and DependencyInjection/Configuration.php rather than relying on blog posts.
• Commands may not appear. Clear the cache after registration:

  bin/console cache:clear --env=dev
  

  Also confirm the bundle is registered in the environment you are using.
• Overwrite risk. Generators commonly replace existing files. Always generate in a clean Git worktree and inspect the diff. Check for --force, --no-interaction, and dry-run-style options.
• Hard-coded path and namespace assumptions. Older generators often assume src/AppBundle or kernel.root_dir. Override templates or configuration if your project layout differs, and watch for getProjectDir() versus kernel.root_dir differences.
• Doctrine edge cases. Associations, inheritance mappings, embeddables, enum-like custom types, and nullable fields often generate incorrect form types or templates. Review generated forms and controllers field by field.
• Route and annotation deprecations. Generated annotations may use older @Route syntax or deprecated service patterns. Check Symfony 3.4 deprecation logs after generating.
• Twig inheritance assumptions. Generated templates expect specific blocks in base.html.twig. Copy and adapt templates instead of editing vendor files.
• Permissions and cache. Ensure var/cache and var/logs are writable by the web/CLI user. Run cache:clear after configuration changes.
• Debugging approach. Run the command with -vvv; inspect the generator command and skeleton templates; generated files are typically Twig-rendered strings, so template errors are the usual cause of malformed output.
• Extension points. The safest extension points are template overrides and wrapper commands. Decorating generator services is possible but brittle because the package is unmaintained.
• Security and hygiene. Never install it in production, never expose generator commands publicly, and audit transitive dependencies since the package no longer receives updates.