- How do I install tey/mod in a Laravel application?
- Install it as a dev dependency with composer require --dev tey/mod, since it is a development-time generator toolkit rather than a runtime library. Publish and adjust its configuration only if you need custom paths; the defaults work out of the box. Then run php artisan mod:list to confirm module discovery before generating anything.
- Does tey/mod support Laravel 12 and PHP 8.3?
- The current release is CI-tested against PHP 8.3 through 8.5 and Laravel 12 through 13, so those combinations are the safest bet. Because it installs as a dev dependency with no runtime surface, the main compatibility surface is the Artisan generator layer. Always confirm the constraints in the package's composer.json before upgrading to a new Laravel major.
- Will tey/mod change how my existing Laravel app generates classes?
- No. The default layout is laravel, which produces output identical to Laravel's own make:* commands, so adoption is zero-risk until you opt into another layout. You can prove this by running mod:list --json and committing the baseline before switching anything. Layout changes happen only through explicit configuration.
- What Artisan commands does tey/mod add?
- It adds roughly thirty mod:* generator commands, including mod:model, mod:controller and mod:dto, which write to wherever your configured layout says instead of Laravel's fixed app/ paths. The generators reuse Laravel's own stubs and conventions, so the output still looks like normal Laravel code. Run php artisan list and filter for the mod: namespace to see the exact set for your version.
- How do I configure where module files are generated?
- Layouts are declarative: you define them in config/mod.php plus Mod::layout(...) calls inside a service provider. File types are registered with ->generates(), group folders with ->path(), and nesting behaviour with ->allowsNesting(). The result is that where a class belongs becomes configuration and a generator default instead of a code-review argument.
- What is mod:autoload and when do I need to run it?
- If your layout has roots outside app/, for example a ddd layout that maps Domain\ to src/Domain/, you must run php artisan mod:autoload so Composer knows about the new namespaces. It is the only place the package writes outside generated source files: it mutates composer.json and shells out to Composer. Treat it as a deliberate, reviewed pipeline step rather than an ad hoc command.
- Can I preview generated files without writing them?
- Yes. Scaffold dry runs show where files would go and, as of v0.7.2, byte-compare existing whole-file members against what the current recipe would write, reporting them as unchanged or edited. That state appears as an optional field in --json output and as a label in human-readable output. Parse the JSON in CI, because v0.7.2 also changed how placeholder warnings are repeated in human output.
- How does tey/mod handle module dependencies and load order?
- It supports dependency-aware loading, letting you control the order in which modules are booted and initialized. Service providers still do the usual booting, binding and extending, so module registration stays inside Laravel's familiar provider workflow. Module discovery is automatic and its search paths are configurable.
- Is tey/mod production-ready and how is it tested?
- It is a dev dependency with no runtime surface, so production risk is limited to your build and code-generation workflow. The engineering signals are strong: around 2,000 Pest tests, PHPStan across src and tests, Pint, a Linux and Windows CI matrix on PHP 8.3 to 8.5 with Laravel 12 to 13, plus a published-API snapshot. The real caveat is maturity: it is still 0.x with a single maintainer, so pin versions and read release notes before bumping.
- How does tey/mod compare to runtime module packages like nwidart/laravel-modules?
- tey/mod is a developer-time code placement and generation toolkit, not a runtime module system: it hooks into Artisan generators so mod:* commands write to your configured layout. Packages like nwidart/laravel-modules centre on bootstrapping modules at runtime, which solves a different problem, and some teams combine both approaches. Choose based on whether you need runtime module registration or mainly consistent file placement and generator defaults.