Review: Modular-based Laravel

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.

I was aware of the laravel-modules package from nwidart, but was never too keen on the structure that it composes.

However, after installing it and tweaking it a little bit, I like the foundation point that i’m at for this application.

Publishable Modules

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 modules folder. 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 modules folder 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.

Pros

• Application can be split up into modules
• Modules can be just composer packages
• Clutter-free repositories
• Separation of concerns and global namespaces

Cons

• 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 modules/ folder.
• Whilst I like the ability to have publishable modules (hosted privately), I’m not too fond of needing to cd into 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.