Plugins Laravel Package

Getting Started

Install and publish

composer require laravilt/plugins
php artisan vendor:publish --tag="laravilt-plugins-config"   # check `php artisan vendor:publish` list for the exact tag

The package builds on spatie/laravel-package-tools, so the service provider registration and config publishing follow that convention — read the provider first, it is the map for everything else.

Where to look first

1. config/ after publishing — this is where discovery paths, enable/disable flags, and stub locations live.
2. The package's stub directory (stubs/) — the generated plugin skeleton tells you more about the expected structure than any docs page.
3. php artisan list filtered to the package namespace — the scaffolding and enable/disable commands are the day-to-day entry points.

First use case

Extract one self-contained feature out of app/ into a plugin. Generate the skeleton with the package's make command, move the models/routes/views in, register the plugin, and confirm the app boots identically. Doing this once on a small feature surfaces every integration point (autoloading, migrations, route registration, asset build) before you commit to a plugin architecture.

Upgrading to v1.1.0

This release is overwhelmingly Dependabot housekeeping (PHPStan, Larastan, Pint, Testbench, spatie/laravel-package-tools, GitHub Actions). The three substantive changes are:

• React support added (#44) — relevant if your plugins ship a frontend.
• Laravel 13 compatibility (#44) — widen your laravel/framework constraint accordingly.
• Plugin dependency handling and generated stubs fixed (#47) — upgrade if you were hitting ordering or stub-generation bugs on v1.0.x.

A composer update laravilt/plugins with a read of the diff is a low-risk upgrade; there are no declared breaking changes.

Implementation Patterns

Plugin-per-feature with a thin host app. Keep app/ for the domain that is your product; push anything optional, tenant-specific, or client-specific into a plugin. This is where the package earns its keep — it turns "we need a custom variant for one customer" into a Composer-level concern rather than a branch in your codebase.

Depend on other plugins, not on the host app. With the dependency handling fixed in #47, declare inter-plugin requirements rather than reaching into app/ classes from a plugin. A plugin that depends on another plugin should state so; loading order is then the package's problem, not yours. Verify your dependency graph after upgrading — this is the change most likely to alter boot order in an existing install.

Customize stubs once, per project. Publish/point the stub path at your own directory so every generated plugin inherits your team's conventions (namespace, base provider, test scaffolding, CI file). Regenerating scaffolds that already match your standards saves the same 20 minutes on every plugin.

Local path repositories for in-development plugins. During development, reference the plugin as a path repository in composer.json with a symlink. You get instant feedback without tagging releases, and you flip to a VCS repository only when the plugin stabilises.

React plugins: build from source. #43 removed the npm publish workflow, so the package's JS is not distributed via npm. If you are consuming the frontend side, build from the vendor path or vendor the components — do not expect an npm-installable artifact. Add the plugin's build step to your deploy pipeline explicitly.

Test plugins in isolation with Testbench. orchestra/testbench is a dev dependency of the package for a reason — the same pattern works for your plugins. Test each plugin against a minimal Testbench app rather than the full host application; it keeps the suite fast and proves the plugin has no hidden coupling to your app.

Keep the package's own tooling out of your runtime. PHPStan/Larastan/Pint bumps in this release are development-only. If you are running static analysis across plugins, pin Larastan in your own composer.json rather than inheriting the package's constraint — the churn in this changelog (3.9.0 → 3.12.0 in one release) shows how fast those move.

Gotchas and Tips

Clear caches after enabling or disabling a plugin. Config, route, and view caches will happily serve a stale plugin list. php artisan optimize:clear should be reflexive whenever plugin state changes, and it must be part of your deploy script if plugin enablement is environment-driven.

Run composer dump-autoload after adding a plugin. Plugin classes are autoloaded via Composer, not discovered at runtime. A "class not found" immediately after installing a plugin is almost always a missing dump, not a broken package.

Stub generation will not overwrite. Generators typically skip existing files. If a stub change in #47 does not appear in your output, check whether the target file already exists before assuming the fix did not land.

Boot order is now meaningful. The dependency-handling fix in #47 means ordering is derived from declared dependencies. If you previously relied on incidental load order (or on composer.json ordering) to make one plugin's service provider run before another's, make that dependency explicit or you may see a behaviour change on upgrade.

Laravel 13 support does not mean Laravel 12 is untested. Testbench and Larastan bumps suggest the matrix is maintained, but if you support both majors, run your own CI against both — do not infer the matrix from a changelog.

Version-pin the package in production. A release that is 95% dependency bumps can still shift boot behaviour (as #47 demonstrates). Constrain to ^1.1 and upgrade deliberately rather than floating.

Watch the spatie/laravel-package-tools constraint. It moved through 1.92.7 → 1.93.2 in this release. If you also depend on it directly, align constraints to avoid a solver conflict that has nothing to do with the plugin package itself.

Extension points worth knowing before you fork. Rather than editing vendor code, look for the package's config-driven discovery paths and its generator/stub customization hooks — those are the supported seams. Forking is a last resort, particularly given how actively this package is being patched.