- Is keljtanoski/modular-laravel a Composer package I can install with composer require?
- No. Modular Laravel is a boilerplate or starter repository, not a distributable library, so there is no Composer package surface or semantic-versioned API to depend on. You adopt it by cloning or forking the repository and taking ownership of every line of code. That is a materially different risk profile from adding a maintained dependency to an existing project.
- Which Laravel and PHP versions does Modular Laravel support?
- The project was last updated in early 2023, so it targets the Laravel and PHP versions current at that time. Check the composer.json constraints in the repository against your own standard before committing. Expect meaningful rework before it runs cleanly on a current Laravel release, since Laravel's skeleton, service provider registration, and PHP floor have all moved since.
- How does Modular Laravel compare to nwidart/laravel-modules?
- Modular Laravel is an opinionated starter scaffold, while nwidart/laravel-modules is a maintained package you add to an existing Laravel application. The package approach gives you an upgrade path and community support; the boilerplate approach gives you a full directory convention but no supported way to pull fixes. For most teams already on Laravel, the package is the lower-risk way to get modular structure.
- How do I install Modular Laravel and create my first module?
- Clone the repository, run composer install and the usual Laravel setup steps, then use the module scaffolding commands it ships with to generate a new module directory. Each generated module can contain its own routes, migrations, views, and service provider. Because it is a boilerplate, treat the first commit as the start of your own codebase rather than an installed dependency.
- Is Modular Laravel suitable for an existing Laravel application?
- Generally no. It is a poor fit for existing applications and for teams standardized on Laravel's default skeleton, because the boilerplate encodes coupling assumptions you would later have to unwind. It is best treated as an architecture reference for greenfield work where the team has already chosen a modular monolith. Extracting just the conventions, such as folder layout and namespace strategy, is usually safer than adopting the whole repo.
- How are module routes, migrations, and views registered in Modular Laravel?
- Each module carries its own service provider, and that provider is where routes, migrations, and views get loaded for the module. This keeps module assets self-contained rather than scattered across the global app directory. Check whether registration is hand-rolled or relies on a third-party loader, since hand-rolled autoloading can break Composer package discovery assumptions.
- Is Modular Laravel actively maintained and production-ready?
- The repository shows a single maintainer, modest star count, and no evidence of an active user base, which is a weak signal for long-term support. Test coverage, static analysis, and CI posture are unverified, so assume none until you confirm. Treat any production use as an early-adopter decision with a named internal owner and an upgrade budget.
- Does Modular Laravel enforce module boundaries or is it convention only?
- The structure is primarily a directory convention; there is no documented mechanical enforcement such as Deptrac or PHPStan rules. That means nothing stops code from reaching across module boundaries once the project grows. If boundary integrity matters to you, plan to add your own static analysis tooling as part of adoption.
- How do I upgrade Modular Laravel to a newer Laravel version?
- There is no supported upgrade path, so you diff against Laravel's upgrade guide for every major between the pinned version and your target, then apply the changes manually. Budget the first upgrade as a real work item rather than a routine chore, and run composer audit alongside a PHP and Laravel compatibility matrix. Because you own the code, dependency drift is invisible to tooling unless you set up Dependabot and audits from day one.
- What are the alternatives to using a modular boilerplate for Laravel?
- You can stay on Laravel's default skeleton and add a maintained module package such as nwidart/laravel-modules, or use Laravel's native package conventions for reusable components. A two-week spike that diffs this scaffold against a clean current Laravel install will usually show which conventions are worth keeping. Many teams extract only the module folder layout and service provider registration, then discard the rest.