nasirkhan/module-manager
Powerful module management for Laravel Starter: track versions, manage migrations, resolve dependencies, and run the full module lifecycle with artisan commands like status, enable, disable, publish, and build.
Architecture: modular monolith vs. microservices. This package makes the "modular monolith" option materially cheaper to evaluate. It gives a working convention for Modules/{Name}/ with its own routes, migrations, views, tests, and a module.json manifest — so a PM can ask "can we ship features as self-contained modules with clear seams?" and get a credible answer in days rather than a quarter. The priority and requires keys in module.json mean load order and intra-app dependencies are declared rather than discovered in AppServiceProvider spaghetti.
Build vs. buy for internal admin/starter scaffolding. If the roadmap includes a CMS-ish back office (posts, categories, tags, menus, activity log), the bundled Post/Category/Tag/Menu/ActivityLog modules are a reference implementation of the pattern, not a product. The decision this informs is "do we buy a CMS or build our own on a modular skeleton?" — the package lowers the build cost but does not replace the buy evaluation.
Feature-flagging and release decoupling. module:enable / module:disable plus module:status gives a coarse, ops-friendly kill switch per feature area. This supports decisions like "ship the billing module dark for two sprints" or "disable the Post module on this tenant/deployment" without branching code.
Upgrade and fork-management policy. The genuinely differentiating capability is module:track-migrations, module:detect-updates, module:diff --detailed, and module:check-migrations. That is a drift-detection story for the classic problem of "we published a vendor module into Modules/ and customized it — what breaks on the next upstream release?" This directly supports a roadmap decision about whether to run a publish-and-fork model (customize freely, accept merge pain) versus an extend-only model (keep vendor code pristine, accept customization limits). Few Laravel module packages address this at all; it is the main reason to look at this one specifically.
Migration-safety posture. getPendingMigrations / hasUpdates are callable from application code, which makes a pre-deploy or CI gate ("block merge if a module has untracked migrations") a small ticket rather than a project. That is a concrete reliability investment a PM can slot into a hardening sprint.
Distribution strategy (only if you have a real plugin story). The namespace-rewrite-on-publish flow implies a vendor → Modules/ handoff model. This supports an early "do we ever let third parties ship modules to us?" decision — and gives an early no if you're honest about the governance cost.
Caveats that must sit alongside any decision: 10 stars, 0 dependents, and a single maintainer (nasirkhan) whose own laravel-starter is the primary consumer. The README describes it as being for Laravel Starter, and the v7.0.0 changelog pushed spatie/laravel-activitylog and intervention/image-laravel into this package as direct, transitive dependencies with declared breaking changes — i.e. installing a module manager also changes your image-processing and audit-logging dependency graph. Also verify the metadata: "last release 2026-11-01" is a future date relative to normal release cadence, so confirm the actual current release before committing to a version pin.
Consider adoption when:
nasirkhan/laravel-starter, or on a starter kit of your own that you are willing to reshape around this convention. In that context it is close to free — the conventions already match.app/," this is a low-ceremony fix.module:build, module:make-test) so that adding a module is a 10-minute task for a mid-level engineer rather than an architecture meeting.Look elsewhere when:
nwidart/laravel-modules is the incumbent and the safer default for anything customer-facing or long-lived. Choosing this package over it is a deliberate bet on simplicity and the migration-drift tooling; make that bet explicitly, not by accident.module:enable/disable reads as deployment-level, not tenant-level — confirm before you architect around it.spatie/laravel-activitylog and intervention/image-laravel is opinionated weight; if you only want the scaffolder and dependency resolver, you'll be stripping code from day one.Verdict for the record: treat this as a reference implementation and a source of two good ideas (declared module dependencies/priority; migration drift tracking) rather than as a strategic dependency. Do not put it on the critical path of a revenue system without a named internal owner.
For executives — one paragraph. This is a small, free (MIT) open-source toolkit that lets our Laravel application be assembled from independent, self-contained modules instead of one large codebase. The business value is change velocity and blast-radius control: teams can add, disable, or remove a feature area without touching unrelated code, and we get tooling to tell us when an upstream module update would conflict with our customizations. It is not a platform commitment — it's scaffolding, and it is replaceable. The cost is effectively zero in license fees and a few engineer-days to evaluate. The risk is concentrated in one maintainer with a tiny user base, so we should treat it as something we adopt-and-own rather than depend on, and we should benchmark it against the established alternative (nwidart/laravel-modules) before standardizing.
For engineering — the honest framing. Two things here are worth stealing even if we don't adopt the package. First, the manifest model: module.json with version, priority, and requires gives us declarative load order and dependency checks (module:dependencies) instead of implicit provider ordering. Second, MigrationTracker — trackModuleMigrations, getNewMigrationsSinceLastCheck, hasUpdates — which turns "did the composer update add migrations we haven't run?" into a boolean we can assert in CI. That is the sharpest tool in the box and it's callable from application code, so a deploy gate is a small ticket.
The rest is conventional and mostly mirrors the nwidart model: module:build to scaffold, module:publish to copy a module into Modules/ with namespaces rewritten, module:diff --detailed to see how far our published copy has drifted from the package version. The publish-and-fork flow is the interesting part and also the trap: once you publish, you own the merge. module:diff mitigates that; it doesn't eliminate it.
Watch the dependency surface. v7.0.0 promoted spatie/laravel-activitylog ^5.0 and intervention/image-laravel ^4.0 to direct dependencies of this package, explicitly so installers can drop them from their own composer.json. That's convenient but it means adding a module manager changes our audit-logging and image-processing stack transitively. Review that diff before merge; it is declared as a breaking change for a reason.
On posture: 10 stars and zero dependents means no community backstop. If we adopt, we pin a version, we own the fork, and we name a maintainer internally. If we don't, we lift the manifest convention and the migration-drift check and skip the rest.
Recommendation. Timebox a spike: one engineer, one sprint, on a non-critical service. Success criteria — (1) a third module can be scaffolded and shipped without editing shared config, (2) a CI check fails when a published module has untracked migrations, (3) a simulated upstream module bump is detectable via module:diff before it breaks anything. If all three land, standardize on it for internal admin surfaces. If not, port the two good ideas into our own base and move on.
How can I help you explore Laravel packages today?