Modules Laravel Package

Product Decisions This Supports

• Modular monolith vs. microservices: Supports keeping a Laravel application as a modular monolith by giving each domain module its own routes, views, config, migrations, commands, and service providers without splitting into separate services prematurely.
• Build vs. buy for module infrastructure: Provides a config-driven module system out of the box, reducing the need to build custom module discovery, route registration, migration orchestration, and module enable/disable tooling.
• Roadmap for modularizing an existing Laravel app: Enables incremental extraction of features into modules while preserving a single deployable application and shared Laravel conventions.
• Platform standardization: Encourages consistent module structure, naming, configuration, and lifecycle management across teams, which helps onboarding and code ownership.
• Feature-flag-style module control: Config-based enable/disable behavior supports environment-specific module loading and safer rollout of optional modules.
• Developer productivity: Auto-discovery, stubs/templates, helper functions, module validation, and migration status commands reduce boilerplate and speed up feature delivery.
• Query ergonomics: Additional query macros such as whereHasIn, orWhereHasIn, whereHasNotIn, random, and groupRandom can simplify common product features like filtered listings and randomized content without custom query code.
• Release-specific reliability improvements: v1.13.10 fixes filesystem exceptions, Request handling exceptions, module name resolution, and module config file compatibility, which lowers integration risk for teams already piloting the package.

When to Consider This Package

• Consider it when:
  • The product is on Laravel 11+ and PHP 8.2+.
  • You want a modular monolith with clear domain boundaries but do not yet need microservices.
  • You need config-driven module enable/disable, dynamic routing, auto-discovery, module migrations, commands, views, and validation.
  • You want to avoid JSON-based module manifests and prefer Laravel-native configuration files.
  • You are standardizing module conventions across multiple teams or planning to modularize a growing Laravel codebase.
  • You need helper functions, view namespaces such as blog::list.test, multi-path module scanning, and module-aware route/controller namespace mapping.
  • You can tolerate a relatively young package and are willing to validate compatibility with your application’s conventions.
• Look elsewhere when:
  • The application is on older Laravel or PHP versions.
  • You need a mature, widely adopted enterprise module platform with a long release history and broad ecosystem support.
  • Your architecture already uses microservices, independent deployables, or a different modularization approach.
  • You require strict long-term API stability and cannot absorb minor-version behavior changes.
  • Your team is unfamiliar with Laravel package conventions or modular monolith patterns.
  • The product needs heavy multi-tenant module isolation, complex permissioning, or module marketplace-style lifecycle management beyond what this package provides.
  • You need vendor-backed support, SLAs, or extensive third-party integration guarantees.

How to Pitch It (Stakeholders)

• Executive summary: This package is a modern Laravel 11+ module system that helps teams ship features faster by organizing the application into configurable, self-contained modules while keeping a single deployable product. It reduces custom infrastructure work and supports incremental modernization without committing to microservices.
• For engineering: Adopt it to standardize module discovery, routing, configuration, migrations, commands, views, and validation. The latest release, v1.13.10, improves reliability around filesystem errors, Request handling, module name resolution, and config-file compatibility, and adds command tooling and improved logic. It is best suited to teams already on Laravel 11+/PHP 8.2+ and comfortable validating a young package.
• For product/roadmap: Use it to support modular feature delivery, safer module rollout via enable/disable configuration, and faster iteration on domain features. It is a build-vs-buy accelerator for modular monolith architecture, not a silver bullet for microservices or enterprise module governance.
• Risk framing: The package is promising but relatively new. Recommend a bounded pilot in one module or service area, verify upgrade behavior and documentation, and avoid making it a hard platform dependency until the team has validated maintainability, release cadence, and compatibility with existing conventions.