Laravel Module Creator Laravel Package

Getting Started

1. Install the package.

   composer require hesammousavi/laravel-module-creator
   

   Laravel's package discovery should register the service provider automatically; if not, add Hesammousavi\LaravelModuleCreator\ModuleCreatorServiceProvider::class to config/app.php.

2. Publish the config and stubs.

   php artisan vendor:publish --provider="Hesammousavi\LaravelModuleCreator\ModuleCreatorServiceProvider"
   

   This gives you config/module-creator.php (module path, namespace, stub locations) and the stub files used to scaffold new code. Read this config file first — it tells you exactly where modules land (typically Modules/ or app/Modules/) and what namespace they get.

3. Confirm the command surface.

   php artisan list | grep -i module
   

   The package exposes scaffolding commands (a make:module-style entry point plus per-artifact generators for controllers, models, migrations, routes). Always run php artisan help <command> before using it in scripts — the flags differ across minor releases.

4. Your first use case: scaffold a vertical slice. Create one module for a self-contained feature (e.g. Billing) with its controller, model, migration, and route file, then register the module's service provider and load its routes. This is the workflow the package is designed around — you get the directory shell and file skeletons, and you fill in the business logic.

Implementation Patterns

• Generate, then customize. Treat the package as a one-time scaffolder, not a runtime dependency. Run the generator, then edit the produced files freely; the package won't overwrite your work unless you re-run a generator over the same path (and even then, most generators skip existing files — verify against the source in vendor/hesammousavi/laravel-module-creator/src).
• Team-wide stubs. Override the published stubs so every new module inherits your conventions: declare(strict_types=1), your base controller, preferred namespace layout, final classes, etc. This is the highest-leverage way to use the package — it turns "new module" into "new module that already looks like our codebase."
• One module = one bounded context. Use modules to group controller + model + policy + migration + routes + tests. Register each module's routes/provider from a single wiring location (a ModuleServiceProvider or the package's auto-registration) so adding a module is a directory-add, not a bootstrap edit.
• Wrap it in your own command. For teams with a fixed module template (auth, feature flags, OpenAPI annotations), add a thin Artisan command that calls the package's generator and then applies post-processing (e.g. registering the module in a manifest JSON). This keeps the "official" module shape in one place.
• Integrate with migrations and seeders. Generated modules typically include their own database/migrations and seeders. Confirm the module service provider calls $this->loadMigrationsFrom(...) — if it doesn't, you'll need to add that wiring manually or your tables won't be created.
• Pair with Composer PSR-4 autoloading. Ensure the namespace the package writes matches a PSR-4 mapping in the root composer.json. If the package doesn't register autoloading, add a mapping for the module root and run composer dump-autoload after generating a new module.

Gotchas and Tips

• Composer autoload is not magic. After generating a module into a new namespace, class resolution will fail until you run composer dump-autoload (or add the path to composer.json autoload.psr-4 and dump). This is the #1 first-run error.
• Config caching bites. If php artisan config:cache is on, edits to config/module-creator.php are ignored. Run php artisan config:clear after changing module paths or namespaces, and re-cache once you're stable.
• Namespace collisions with nwidart/laravel-modules. Both packages want the Modules\ namespace and a Modules/ directory. Do not install both. If you're migrating, uninstall one fully before generating with the other, or you'll get duplicate-provider and duplicate-autoload errors.
• Path and Windows quirks. Module paths in config are usually passed straight to File::makeDirectory. Use forward slashes in config; absolute paths from a Windows environment can break stub rendering. Also watch for trailing-slash duplication in generated namespaces.
• Stubs are the extension point. Rather than post-processing generated files everywhere, edit the published stubs. Any change you'd make by hand to a fresh module belongs in the stub. Re-publish stubs after upgrading the package, since upstream may ship changes.
• Registration is not automatic by default in many small packages. After generating, confirm the module's service provider is registered (either in config/app.php, bootstrap/providers.php on Laravel 11+, or via a manifest). If routes 404 or migrations don't run, the provider is almost always the culprit.
• Debugging. When a generated file doesn't appear where expected, dump the resolved config (php artisan tinker → config('module-creator')) and check the source in vendor/hesammousavi/laravel-module-creator/src/Commands — with 25 stars, documentation is thin and the code is the source of truth.
• Version pinning. Small packages churn. Pin a minor version in composer.json and read the changelog on upgrade; command signatures and stub variable names are the most likely break points.
• Don't over-modularize. The cost of this package is directory sprawl. Reserve modules for genuinely separable features; small additions belong in app/ as usual.