Laravel Modular Laravel Package

Technical Evaluation

Architecture fit The package implements a modular monolith — bounded contexts as first-class directories under modules/ with their own providers, routes, migrations, configs, stubs, and even composer.json/package.json. For a TPM, this is the sweet spot between a single Laravel app and premature microservices: it gives namespace isolation and enforced dependency ordering (topological boot) without distributed-system overhead. It fits teams that want DDD-lite decomposition, team-per-module ownership, or reusable domain packages. It is not a plugin/marketplace system (despite dynamic enable/disable); it's a compile-time architecture convention.

Integration feasibility Low-friction at the surface: composer require + php artisan modular:install, plus a documented manual path (PSR-4 Modules\ mapping and Vite config). The modular:install step auto-installs and configures wikimedia/composer-merge-plugin — that dependency is the single biggest integration wrinkle (plugin allow-listing, CI behavior, and the project's own recommendation to run modular:sync and then disable the merge-plugin for production). Vite integration requires editing vite.config.js to consume vite.modular.js. Feasible in a day for a competent Laravel dev; not zero-touch.

Technical risk

• Single maintainer / low signals: 23 stars and 0 dependents means no external validation. Treat it as a strategic dependency and budget for fork/self-maintain.
• Command overrides: 29+ overridden Artisan generators are invasive and couple to Laravel internals; Laravel 12→13 upgrades are the likely breakage vector.
• Autoload merging: composer-merge-plugin is a historically finicky dependency; classmap collisions and CI surprises are the expected failure class.
• Boot ordering: topological sorting on a dependency graph is powerful but opaque when wrong (modular:check helps, but circulars still surface at runtime if misconfigured).
• Ecosystem breadth: Livewire/Filament/Hooks/Themer are separate packages — each adds its own maintenance delta.

Key questions

1. Who is on the hook when Laravel 13 ships and generators break — vendor, maintainer, or us? What's the fork policy?
2. Is modular:sync viable as the permanent production posture, eliminating the merge-plugin entirely?
3. What's the documented upgrade/BC policy and test matrix (Laravel 11.x/12.x, PHP 8.2/8.3/8.4)?
4. How does discovery caching (modular:cache) interact with module:enable/disable in staging vs. production?
5. Are we comfortable with an unpadded dependency tree (Filament/Livewire ecosystem packages) where the core is still pre-1.0 signal (changelog exists, but no stable major line stated)?
6. Does the frontend team own vite.modular.js + NPM workspaces as a supported workflow?

Integration Approach

Stack fit PHP 8.2+ / Laravel 11–12, Composer, Vite, Pest — all table-stakes for a modern Laravel shop. The modular config('Blog::settings.key') case-insensitive convention and module(), module_path(), module_asset(), @moduleEnabled Blade directives slot cleanly into existing patterns. Filament/Livewire integration is optional and additive; don't bundle that decision into the initial rollout.

Migration path (strangler-style)

1. Spike — install in a throwaway branch, run make:module Blog, exercise modular:list --tree, modular:doctor, modular:check, a generate-model-with-migration flow, and a Vite build. Measure modular:cache cold/warm.
2. Pilot one bounded context — extract one low-risk domain (not auth, not billing/tenancy) into modules/<X>, keeping route/event/migration semantics intact. Validate against a full test suite.
3. Harden — run modular:sync to fold module dependencies into the root composer.json and disable the merge-plugin; add modular:cache to the deploy pipeline.
4. Scale — repeat per bounded context, gated on modular:doctor staying green.

Compatibility

• Confirm Laravel 11/12 only (no 10 back-support), PHP 8.2+ floor.
• Audit existing packages that hardcode App\... or expect app/ layout; Modules\ PSR-4 must not collide.
• Confirm modular:test and existing Pest suites both run in CI.
• Confirm vite.modular.js coexists with whatever Vite config the team already has (input/refresh arrays).

Sequencing Spike → domain extraction → CI hardening (doctor, check, cache) → deploy-pipeline changes (modular:migrate, asset link) → optional ecosystem add-ons (Livewire, Filament, Hooks) only after core is stable. Keep the merge-plugin disabled in production before go-live.

Operational Impact

Maintenance Changelog and tagged releases exist (last release 2026-07-08), README and docs/ are credible, MIT license is clean. But: single maintainer, 23 stars, no downstreams. Plan for a fork + internal patch lane on the generator overrides, and pin the version. Track Laravel's make:* changes each minor as the trigger for a regression run.

Support Community/GitHub issues only — no commercial SLA. Sponsor link exists but is not a support contract. This is acceptable for an internal framework convention, not for compliance-locked deliverables. Escalation must be internal.

Scaling Two axes matter. (a) Module count: discovery caching (modular:cache) is designed for this and is the key production lever; watch cold-boot time as modules grow and modular:list --tree to spot dependency depth. (b) Frontend: NPM workspaces via modular:npm scale, but asset link/publish (modular:link) must be part of every deploy or images/CSS 404.

Failure modes to design for

• Circular dependency → boot failure (modular:check in CI).
• Composer-merge-plugin failing on CI runners / plugin allow-list churn.
• Stale modular:cache after module:enable/disable → 404s or missing routes.
• Namespace/class collisions from PSR-4 merging.
• Generator override drift after a Laravel minor.
• Migration ordering across modules in deploys — must be explicit, not implicit.
• Asset link orphaning after renames.

Ramp-up For devs fluent in Laravel's make:* and artisan migrate, --module= is a near-native leap: roughly 1–3 days to productive, plus concepts for module.json, the ModuleRegistry, topological boot order, and module-scoped config. Frontend devs need half a day on vite.modular.js and workspaces. The TPM artifact that pays for itself: a short internal "modular conventions" doc covering dependency rules, generator usage, deploy checklist (doctor → check → cache → migrate → link), and the fork/patch policy. Do that before scaling beyond two modules.