- How do I install daniel-cintra/modular in a Laravel project?
- Installation is done through Composer, typically as a dev dependency since the package works as a scaffold and code generator rather than a runtime library. After requiring the package, you run the provided Artisan command to generate the modular application structure, then commit the generated code to your repository. Check the repository README for the exact command name and any publishable config or stub files. Because the generated output becomes your own application code, you can remove or pin the dev dependency once scaffolding is complete.
- Is daniel-cintra/modular a runtime dependency or just a scaffolding tool?
- It is best understood as an opinionated application scaffold and code-generation toolchain for the Laravel, Inertia.js, Vue and Tailwind stack. It is a build-time dependency rather than a runtime one, so once the scaffold is generated and committed, the package largely sits outside the production request path. The modules it creates do include their own service providers, routes and config, but those are files you own and control. This is a favorable risk profile because nothing forces the package itself into your production dependency graph.
- Which Laravel, PHP, Inertia, Vue and Vite versions does daniel-cintra/modular support?
- The package does not publish a detailed, prominently maintained compatibility matrix, so you should verify the constraints in its composer.json and the generated package.json before adopting it. The scaffold pins a specific combination of Laravel, PHP, Inertia v1 or v2, Vue 3 and Vite at the time it was generated, and those pins are point-in-time artifacts. Confirm the versions match your target environment and check recent commits or releases for signs of active version maintenance. Treat the supported matrix as something you validate yourself rather than something formally guaranteed.
- Can I use daniel-cintra/modular in an existing Laravel application?
- Brownfield fit is weak to moderate: retrofitting the module convention onto an existing app is a restructuring exercise with limited payoff. The package assumes ownership of a significant portion of the app and resources/js layout, so partial adoption is awkward. A more realistic approach is to borrow the module conventions and directory structure manually rather than adopting the toolchain wholesale. Reserve full adoption for greenfield projects where you control the layout from day one.
- How does daniel-cintra/modular structure modules?
- Each module is self-contained and carries its own routes, controllers, models, migrations, views, config and service providers. That convention keeps features isolated so a module can be reasoned about, tested and removed without untangling the rest of the application. Routes are registered through the module service providers, and namespaces follow a directory convention rather than heavy tooling. Boundary enforcement is primarily convention-based, so static analysis rules and code review standards are your main guardrails.
- Does daniel-cintra/modular work for API-only, Livewire or React projects?
- No, the package is tightly coupled to the Laravel plus Inertia.js plus Vue 3 plus Tailwind stack. It is a poor fit for API-only services, Livewire-centric teams and React shops, since the scaffold's conventions assume a Vue SPA front end. Livewire or API-only teams would end up stripping out most of the generated front-end structure. If your organization already maintains an in-house Laravel starter template, that internal asset should win by default.
- Does the generated app include tests and CI configuration?
- Testing support is not the package's focus, so plan to add your own harness rather than assuming one ships with the scaffold. Budget time for Pest or PHPUnit on the PHP side, Vitest or an equivalent for the Vue components, and CI wiring for both. Also expect to adapt the generated output to your linting rules, PHPStan or Psalm baselines and Docker setup. Treat the scaffold as a starting point that needs an adaptation pass, not a drop-in production template.
- What are the maintenance and bus factor risks of daniel-cintra/modular?
- The package has roughly 176 GitHub stars, a single named maintainer and no commercial backing or observable support contract. That is acceptable for a scaffold whose output you own, but unacceptable as a foundation you cannot replace. The module convention also becomes a de facto internal standard, so a future divergence in maintainer opinion means a refactor rather than a version bump. Mitigate by snapshotting the generated code, pinning versions and documenting your own conventions independently of the package.
- How do I upgrade daniel-cintra/modular or handle Laravel version drift?
- There is no documented upgrade path between package versions, so re-scaffolding into a fresh project and porting your modules is the likely intended model. Generated code is a point-in-time artifact, and Laravel, Inertia, Vue and Vite will all move faster than the scaffold does. Keep your dependency versions pinned, track upstream security releases yourself and plan manual upgrades for the front-end and framework layers. Also note that you inherit the security posture of whatever Laravel and Node versions the scaffold pins, regardless of the package's health.
- What are the alternatives to daniel-cintra/modular?
- Common alternatives include Laravel Breeze or Jetstream for the Inertia and Vue starting point, and nwidart/laravel-modules if you want a more established modular package with a larger user base. Many teams simply maintain an internal Laravel starter template tuned to their CI, static analysis and code review standards. If you only want the module folder convention, implementing it in-house is low effort and removes the external dependency entirely. Compare adoption against that incumbent before committing.