Laravel Modular

Appearance

Upgrade guide ​

This package follows Semantic Versioning. Patch and minor releases are backward compatible; breaking changes only land in major versions and are listed here.

Migrating from another modules package ​

The layout is intentionally compatible, so most projects migrate without touching their modules:

  1. Keep your structure. The Modules/ directory, module.json, and modules_statuses.json are read as-is.
  2. Publish the config.
    bash
    php artisan vendor:publish --tag=modules-config
  3. Point providers at the new base class. Change a module's provider to extend Dem1Off\LaravelModular\Module\ModuleServiceProvider; config, migrations, views and routes then load by convention. Declare bindings and listeners with attributes.
  4. Keep app-specific concerns in your app. Anything proprietary (navigation, mailing, metrics, …) stays in your application, invoked from the module's boot() — see Customising behaviour.

Within v1.x ​

Minor and patch releases are backward compatible for application code — your modules, config and the artisan command signatures are unaffected. Breaking changes to the public runtime API only land in the next major (v2) and are listed in the Changelog.

1.6.0 — re-run module:cache ​

The compiled settings now carry each module's resolved convention paths, so a cached boot never stats the filesystem. Rebuild once after upgrading a deployment that uses the compiled cache:

bash
php artisan module:cache   # or: php artisan optimize

An older cache without the paths still boots — the provider falls back to resolving folders live — so nothing breaks before you rebuild; you just don't get the saving yet.

Note the new contract that comes with it: with a cache present, adding a convention folder (routes/, lang/, config/, …) to a module needs a module:cache rebuild to take effect, the same as config:cache. Development, which runs without the cache, is unaffected.

1.5.0 — re-run module:cache ​

The compiled settings now carry the translation toggle and the commands discovered from Console directories. After upgrading a deployment that uses the compiled cache, rebuild it once:

bash
php artisan module:cache   # or: php artisan optimize

Everything else is additive — translations, command discovery, the new generators, requires and module:check --boundaries change nothing for modules that don't use them.

1.3.0 — custom generators ​

1.3.0 moved each command's logic into a console-free Operations layer. This is invisible to applications, but if you subclass ModuleGeneratorCommand to add a custom generator, replace the old stub(), layerPath(), layerNamespace() and classSuffix() methods with a single layer(): ClassLayer — see Custom in-module generators.