Generator Bundle Laravel Package

Getting Started

Before anything else: this is not a Laravel package. zikula/generator-bundle is a Symfony bundle built for the Zikula Application Framework (a CMS/application platform on top of Symfony). There is no service provider, no facade, no config/generator.php, and it will not install cleanly into a standard Laravel app. Treat it as a reference implementation, not a dependency.

If you are genuinely working inside a Zikula install (Core 2.x/3.x era), the minimal path is:

1. composer require zikula/generator-bundle in the Zikula project root (not a Laravel project).
2. Register the bundle in app/AppKernel.php (Symfony 2/3 style) or config/bundles.php depending on the Zikula core version.
3. Run the generator from the Zikula console: bin/console zikula:generate:module (the exact command name varies by version — run bin/console list zikula to confirm).
4. Answer the interactive prompts (vendor, module name, description) and inspect the generated tree under modules/<Vendor>/<ModuleName>/.

Where to look first: the generated module's composer.json, <ModuleName>Module.php (the bundle class), and Resources/config/routing.yml. Those three files tell you how the scaffold wires itself into Zikula's kernel, autoloading, and routing.

First real use case: scaffolding a fresh Zikula module with the correct directory layout, PSR-4 autoload entry, and boilerplate controller/entity/template so you don't hand-copy an existing module.

Implementation Patterns

Skeleton-then-edit. The generator's value is the file layout, not ongoing runtime behavior. The typical workflow is: generate once, commit the output, then delete the dependency or leave it in require-dev. There is no reason to keep the generator in production dependencies.

Template source of truth. If you maintain multiple Zikula modules, the practical pattern is to generate one "golden" module, clean it up to your house style (coding standards, CI config, editorconfig, base controller), and then copy that for future modules rather than re-running the generator. The archived generator emits dated boilerplate that you will immediately rewrite.

Generated file inventory. Expect the generator to produce:

• <Vendor>/<Module>/<Module>Module.php — the bundle class
• composer.json with a PSR-4 mapping for the module namespace
• Controller/ with a default controller extending Zikula's AbstractController
• Resources/config/routing.yml, Resources/views/, Resources/locale/
• Entity/ and Doctrine wiring stubs
• Api/ stubs for Zikula's module API pattern

Integration into a Zikula app. After generation you must (a) run composer dump-autoload, (b) confirm the module is registered/activated in the Zikula admin UI or modules table, and (c) clear the cache (bin/console cache:clear). Zikula's module activation step is separate from Symfony bundle registration — a generated bundle that is registered but not "activated" as a Zikula module will not expose routes.

Laravel-adjacent takeaway. If you're evaluating this while building Laravel tooling, the transferable ideas are the prompt-driven vendor/namespace derivation and the per-artifact templates. For actual Laravel scaffolding, laravel new, php artisan make:*, and packages like nwidart/laravel-modules cover the same ground with a maintained ecosystem.

Gotchas and Tips

• Archived and unmaintained (last release 2019-03-26). No security patches, no PHP 8.x or Symfony 5+/6+ compatibility guarantees. Do not add it to a project with modern dependency constraints — Composer will fight you on symfony/* and zikula/core version pins.
• Ecosystem mismatch. Installing into Laravel will fail on autoloading and bundle registration. It targets Zikula's kernel and console, not Laravel's Artisan.
• Command name drift. The generator command name and argument set changed across Zikula 1.x/2.x/3.x. Always run bin/console list and read --help rather than trusting tutorials.
• Overwrite danger. Like most Symfony-era generator bundles, it will happily overwrite existing files if you point it at an existing module directory. Generate into a clean path and diff before committing.
• Namespace validation is strict. Zikula enforces a Vendor\Module naming convention (studly-case, no digits-first). A name that "looks fine" often fails validation, or produces a PSR-4 mapping that doesn't match your composer.json autoload block.
• Autoload caching. If the generated module 404s, the usual cause is a stale Composer autoloader or Zikula cache — composer dump-autoload then bin/console cache:clear fixes most "class not found" and "route not found" symptoms.
• Activation vs. registration. Registering the bundle in the kernel is not the same as activating the Zikula module. Forgetting the activation step is the single most common reason a freshly generated module shows nothing.
• Extension points are minimal. The generator is template-driven but not designed for swapping in your own templates via config — customization means forking it. Given the archive status, forking is arguably the only sane path if you must use it.
• Treat the output as a starting draft. Generated Doctrine entities, controllers, and templates are deliberately generic; expect to rewrite most of the controller body and every template. The generator saves you maybe 20 minutes of mkdir/touch, not real design work.