I’ve decided to revitalize an old project I had started creating from 2017. One of the requirements were to make it modular based, on a core level, and for extensions.
However, after installing it and tweaking it a little bit, I like the foundation point that i’m at for this application.
Laravel modules is designed to separate your application into modules, and as part of the documentation, it provides instructions on creating packages from your modules. At first, I didn’t like this idea, because it mean’t maintaining multiple repositories for the application. However, after consideration and a quick demo, I found some benefits from this:
- Separating them into packages (whether it be a public package registered on packagist.org, or a private package) is actually neat. It means whenever you change a module, you’re not committing the main repository with a
modulesfolder. You simply change directory via the command line, or use a GUI like GitKraken or Github Desktop, and commit the changes directly for that module. It keeps the main application clutter-free and commit-free.
- laravel-module-installer is a package that searches for modules in your application when you run
composer install. Once it discovers a package, it doesn’t continue with downloading it into the vendor folder, it moves it to a
modulesfolder in the root directory of your main application.
Pros and Contras
As with any application, there are pros and cons as to how an application is developed and structure, for the long-term.
- Application can be split up into modules
- Modules can be just composer packages
- Clutter-free repositories
- Separation of concerns and global namespaces
- Based on the structure of the laravel-modules package, the
app/directory in your application is no longer used, even for shared resources. In general, you’ll created a Shared module which is a dependency for all other modules. This almost feels like a waste of a Laravel application, since 99% of the time, you’re working in the
- Whilst I like the ability to have publishable modules (hosted privately), I’m not too fond of needing to
cdinto modules and committing on a regular basis, multiple times, over and over, and over, and over
Overall, I’m 90% satisfied with using laravel-modules in the application. I needed something that was well-structured, and potentially re-usable in case I need to test within another application. The DDD approach didn’t work so well for me, as I’m not a fan of nested folding, and it only solves the issue of application code, not resources and assets.
I wouldn’t suggest this in a small application, the default folder structure suffices well. But once you feel like your application is getting out of control, try looking into Laravel modules.