- How do I install nasirkhan/module-manager in a Laravel app?
- Install it with composer require nasirkhan/module-manager. The published requirements are PHP 8.3 or higher and Laravel 12 or 13, so confirm those constraints resolve against your lockfile before committing. After install, run php artisan module:status to list discovered modules, module:dependencies to verify load order, and php artisan migrate to apply pending migrations.
- How does module:publish work and why do I need composer dump-autoload afterwards?
- module:publish copies a bundled module into your app's Modules/ directory and rewrites namespaces from Nasirkhan\ModuleManager\Modules\{Module} to Modules\{Module}. Because it performs install-time source rewriting, you must run composer dump-autoload and php artisan config:clear immediately afterwards or you get silent class-not-found failures at runtime. The command is not idempotent in practice, so re-publishing over an existing module can overwrite local edits.
- How do I track module migrations and detect new ones after a composer update?
- Run php artisan module:track-migrations to record the current migration state as a baseline, optionally with --force to re-baseline. After upgrading the package, run module:detect-updates to see which modules shipped new migrations, and module:check-migrations for any that have not been published yet. Re-baselining carelessly can mark migrations as applied that never ran, so review the diff before forcing.
- How are module dependencies and load order resolved?
- Each module declares its requirements in a module.json requires array, and load order is controlled by an integer priority value. Run php artisan module:dependencies to check whether every requirement is satisfied and to see the resolved order before enabling anything. This registry is the package's own and separate from Composer, so missing or circular entries surface at runtime rather than at install time.
- Is nasirkhan/module-manager a replacement for nwidart/laravel-modules?
- Not really. nwidart/laravel-modules remains the incumbent for module discovery, publishing, and scaffolding in general-purpose Laravel applications, and nothing in the recent releases changes that. nasirkhan/module-manager targets Laravel Starter and adds its own migration baseline tracker plus four bundled modules (Post, Category, Tag, Menu) that many teams would rather not install at all.
- Which Laravel and PHP versions does module-manager support?
- The documented pins are PHP 8.3 or higher and Laravel 12 or 13, as last evidenced at v6.9.0. The package has since crossed two major version lines to v8.4.1 with no published upgrade guide, deprecation notice, or breaking-change summary. Re-confirm the constraint in the package's composer.json before quoting version support to stakeholders.
- Does module-manager require the Laravel Starter kit?
- It is designed for Laravel Starter and assumes the Modules/ directory convention that starter kit uses. It can run in a plain Laravel app, but you inherit the bundled Post, Category, Tag, and Menu modules and their CMS domain code, which most non-starter projects do not want. Run module:publish on one module first and inspect what actually lands in your source tree.
- How do I enable, disable, or remove a module?
- Use module:enable and module:disable to toggle a module's state without deleting files, and module:status to view state, versions, and dependency satisfaction for all modules or a single named module. module:remove deletes a module, so run module:diff first to see how your published copy diverges from the package version. Disabling does not remove already-applied migrations.
- Can I scaffold a new module and generate tests with it?
- Yes. module:build scaffolds a new module with the expected module.json, Config, Console, and related structure, while module:make-test generates a test class for a module with an optional --unit flag. If you are unsure which command applies to a workflow, module:help with a topic prints the command reference and typical sequences.
- What are the production risks of adopting module-manager?
- The main ones are a single-maintainer bus factor, very little adoption signal, and silent major-version churn from 6.9.0 to 8.4.1 without published upgrade notes. Install-time namespace rewriting and the migration baseline tracker are the highest-risk moving parts, so any spike work done against 6.x or 7.x should be re-run on 8.x. If you strip the bundled CMS modules you forfeit their bug fixes, since the only change in v8.4.1 was a fix to the bundled Menu module.