Module Laravel Package

Getting Started

Install the package via Composer (composer require panelis-php/module) and publish its configuration if provided (php artisan vendor:publish --tag=module-config). Start by reading the package's README and the config/module.php file to understand module discovery paths and registration conventions. The first practical use case is creating a module (likely via an artisan command such as php artisan module:make Blog) and then, with v1.4.0, registering permissions that belong to that module. In your module's service provider, use the new permission registration API (check the package docs for the exact method name—likely registerPermissions() or a facade call) to declare permissions like blog.manage and blog.publish. This immediately lets you tie module functionality to Laravel's authorization layer (e.g., Gate or a permissions package) without scattering permission definitions across the main app.

Implementation Patterns

Modules are typically registered through a central service provider or a config-driven registry. Each module has its own service provider where you can define routes, migrations, views, and now permissions. The v1.4.0 permission registration fits naturally in a module's boot() method: declare an array of permission names and descriptions, then let the package sync them. Day-to-day workflow: generate a module, add your domain logic, register module-specific permissions in the provider, and assign those permissions to roles using your authorization package of choice (e.g., spatie/laravel-permission). Integration tip: keep permission names namespaced with the module name (e.g., blog.manage) to avoid collisions. If your app uses a permission cache, run the package's sync command or clear the cache after registering new permissions. You can also conditionally register permissions based on config flags, enabling you to ship modules that are disabled by default but still expose their permission definitions when activated. For larger apps, consider a dedicated PermissionServiceProvider per module that is loaded only when the module is enabled.

Gotchas and Tips

Permission registration likely happens during the service provider boot cycle, so ensure your module providers are loaded after any underlying authorization package is booted—otherwise permissions may not be recognized. Clear permission caches (e.g., php artisan permission:cache-reset or php artisan cache:clear) after adding or changing permissions, as stale caches are a common source of "permission not found" errors. Watch for naming collisions: always prefix permissions with the module name. If the package uses a config file for module paths, double-check that your module's namespace is autoloaded in composer.json and that the module is registered in the correct order (especially if modules depend on each other). Debugging tip: use php artisan module:list (or the package's equivalent) to verify modules are discovered, and inspect the registered permissions via a custom artisan command or by dumping the permission repository. Extension point: if the permission registration API is not flexible enough, you can override the module's service provider or listen to module registration events to inject your own permission logic. Finally, review the v1.4.0 changelog and PR #14 for the exact method signature—small API differences between register() and boot() can cause silent failures if permissions are registered too early.