Download the PHP package syscage/laravel-plugin without Composer

Syscage Laravel Plugin

A WordPress-style plugin framework for Laravel 12+ applications. syscage/laravel-plugin turns a plugins/ directory in your host application into a set of independently discoverable, installable, and toggleable Laravel packages — each with its own routes, views, translations, migrations, config, assets, and console commands — without ever running composer dump-autoload.

This package does not manage your application's modules or its own business logic; it manages the plugins that live inside plugins/ in your host application.

Installation

Creating a plugin

make:plugin scaffolds the full plugin directory structure:

plugin.json is the plugin's manifest — name, alias, version, its service provider's class name, dependencies, permissions, and sidebar contributions. src/Plugin.php extends Syscage\Plugin\AbstractPlugin and exposes every path a manager or command needs ($plugin->viewPath(), $plugin->migrationPath(), ...) plus lifecycle hooks (install(), uninstall(), enable(), disable(), update()) you can override. The plugin's own service provider extends Syscage\Plugin\PluginServiceProviderBase, which auto-wires routes, views, translations, migrations, config, assets, and console commands for you.

Plugin lifecycle

requires/conflicts in plugin.json are validated (including semver version constraints) before install/enable, and a plugin's loading order is resolved topologically by its dependencies, then by priority. Unlike plugin:uninstall (which only removes the database record and runs the plugin's uninstall() hook), plugin:delete removes the plugin from everywhere — it's the one to reach for when you want a plugin fully gone, and it's resilient enough to also clean up a plugin whose directory was already removed by hand, leaving only an orphaned database record and stale caches behind.

Customizing the plugin record model

Installed-plugin state (UUID, install/enable timestamps, priority, ...) is persisted through Syscage\Plugin\Models\PluginRecord, an ordinary Eloquent model. Extend it with your own model — to add relationships, casts, or move it under your app's own namespace — and point the model key in config/plugin.php at your subclass:

Every plugin command and manager resolves the record through this config value, so they'll return instances of your subclass instead of the base PluginRecord.

Caching

Generating a new plugin (make:plugin) automatically invalidates the discovery cache, so the next Artisan process picks it up without a manual plugin:discover.

Friendly generator aliases

Every plugin-scoped counterpart of Laravel's own generators and database commands is available, redirecting output into the target plugin instead of the host application:

Every alias accepts {plugin} as its first argument (the plugin's alias or manifest name) followed by exactly the same arguments and options as the Laravel command it wraps. The full list:

Generators — each writes into the target plugin's src/ tree under its own namespace instead of the host app's app/:

Migrations — scoped to the target plugin's own src/database/migrations directory:

Database:

Framework/cache/queue/testing:

config:cache-plugin, route:cache-plugin, view:cache-plugin, event:cache-plugin, and optimize-plugin still require {plugin} for command-family consistency, but rebuild the shared, application-wide cache — they don't scope it to one plugin.

db:seed-plugin relies on that DatabaseSeeder existing; make:plugin scaffolds an empty one for you at src/database/seeders/DatabaseSeeder.php. Plugin seeders are never run implicitly by the host app's own php artisan db:seed — call them explicitly from your host DatabaseSeeder::run() (e.g. $this->call(\Plugins\BlogPost\Database\Seeders\DatabaseSeeder::class);) if you want them included.

Frontend integration

For React/Vue/Inertia hosts (auto-detected from package.json, or set explicitly via plugin.frontend in the published config), plugin:cache generates bootstrap/cache/plugins.ts containing every plugin's page component imports (from resources/js/Pages), routes, and sidebar entries — read by your frontend build instead of editing app.tsx/app.ts directly.

Architecture

Every framework responsibility is its own single-purpose class behind an interface, resolved via the container — see src/Contracts/. Plugin Discovery, the Plugin Registry, the Dependency Resolver, the Plugin Manager/Loader/Lifecycle, and each resource manager (Route, View, Translation, Migration, Config, Asset, Command) can each be swapped independently. The package reuses Laravel's own building blocks throughout — its Router, Translator, Migrator, config repository, filesystem, and generator commands — rather than duplicating them.

Testing

Documentation

Full documentation lives in doc.syscage.com/laravel-plugin: