Filament Modular Luncher Laravel Package

Getting Started

This package is a Filament control center for Laravel Modular 1.2 applications — it does not manage modules itself, it gives you a UI and a set of ops tools on top of the core package. Install order matters:

1. composer require the package (it requires laravel-modular ^1.2, Laravel 12/13, PHP 8.3–8.5).
2. Publish the config and assets (vendor:publish for the tagged config and Filament assets).
3. Register the plugin in your panel provider (->plugin(...)), typically on an admin or ops panel rather than a customer-facing one.
4. Run php artisan migrate if the package ships any tables, then open the module resource in the panel.

Where to look first, in this order:

• resources/boost/guidelines/core.blade.php — the Laravel Boost guidelines shipped in this release. Even if you don't use Boost, this file is the most concise statement of how the package expects to be used and is a good source of prompts when you ask an AI assistant to scaffold module install flows.
• config/ — specifically the Composer vendor allowlist and remote URL host allowlist keys. These are optional and off by default, which is the single most important thing to know before you expose the install UI to anyone.
• Docs for upgrades, diagnostics, and security — the new upgrade guide matters if you were on a pre-1.1 install, because install execution paths were rewritten.
• README.md — feature coverage was expanded in 1.1.0 and is now a decent map of the action surface.

First realistic use case: open a module and run the Module Doctor action. It reads the manifest, checks ecosystem metadata (requires, conflicts, provides, middleware, policies, events), and returns diagnostics without mutating anything. That gives you a baseline before you touch installs.

Implementation Patterns

Panel-scoped registration. Register the plugin only on the panel where ops staff live. Health badges and the Module Doctor action are read-heavy and expose dependency topology you probably don't want in a tenant or customer panel. If you run multiple panels, gate registration behind an environment or role check in the provider rather than relying on Filament authorization alone.

Badges as a dashboard signal. The four badge states (healthy, disabled, dependency review, conflicts) map cleanly onto a table column and a widget. A common pattern is a ModulesHealthWidget that counts by badge state, plus the badge as a column on the module resource table. Treat "dependency review" as advisory — it flags that a module's requires/conflicts set changed relative to what's installed, not that anything is broken.

Action chaining for triage. The four new actions form a natural escalation path: Explain Module (what is this and what does it need) → Status Report (current runtime state) → Module Doctor (why is it unhealthy) → Debug JSON (raw manifest for bug reports). Wire the last one to a "copy to clipboard" or download so support tickets carry structured evidence instead of screenshots. Debug JSON output is also the right thing to attach to a Laravel Modular issue.

Install flows behind allowlists. Four install sources now exist: Composer, ZIP, URL, and Git. The pattern that holds up in production is deny-by-default: set the Composer vendor allowlist and the remote URL host allowlist in config, and treat the install actions as super-admin-only. Git installs need the PHP process to have credentials (deploy key or SSH agent) — decide deliberately whether that's the web user or whether Git installs are restricted to a queue worker running as a deploy user.

Ecosystem metadata over code reading. Rather than grepping a module's service provider to find its middleware or policies, surface middleware, policies, and events from the manifest in the resource's infolist or a relation manager. This is especially useful during code review of a third-party module before you enable it.

CI alignment. If you maintain modules against this package, mirror its own CI posture: Pint scoped to package-owned paths, PHPStan in the main workflow, and a test matrix that skips Laravel 11 (Composer security advisories block those installs). Running Pint unscoped on a monorepo is what the 1.1.0 fix was working around — scope your formatting checks the same way.

Gotchas and Tips

• Allowlists default to permissive. Optional vendor and host allowlists mean an unconfigured install is an unconfigured install. Set both before exposing install actions, and remember the URL allowlist applies to the initial request, not to redirects — validate what you actually need at the host level.
• removeable vs removable. Both manifest spellings are now accepted. If you generate manifests programmatically or validate them in your own code, accept both, and don't "fix" one into the other in a migration without checking what Laravel Modular 1.2 reads.
• Redacted URLs in failures. Operation failures now strip secret-bearing URLs. This is the right behavior, but it means your error logs will show a placeholder where a token-bearing clone URL used to be. If you need the full URL for debugging, reproduce the operation manually rather than expecting it in the failure message.
• Git and Composer execution is arg-safe now. Shell interpolation was replaced with process arguments, so passing unusual characters in a package name or branch is safe — but it also means anything that previously relied on shell expansion (globs, ~, environment variable substitution in a URL) will no longer expand. Pass explicit values.
• HTTP installs now time out. Remote URL installs validate the response and apply a timeout. Large module archives on slow origins will fail where they previously hung indefinitely. Raise the timeout in config rather than retrying blindly.
• ZIP hardening changes failure modes. Absolute paths and ../ traversal are rejected. Archives that installed fine on 1.0.x may now be refused — that's correct behavior, but it's the most likely upgrade surprise. Repackage with relative, non-escaping paths.
• Debug JSON is the extension point. When the built-in actions don't answer a question, the raw manifest plus the ecosystem metadata fields is what you build custom Filament actions against. Avoid reaching into the model's internals; go through the manifest.
• Upgrade order. Bump Laravel Modular to 1.2 first, then this package. The 1.1.0 model compatibility changes assume the 1.2 manifest fields exist; installing in the other order gives you nulls where metadata should be.
• PHPStan and Pint are now enforced upstream. If you vendor or fork any part of this package, expect stricter static analysis than 1.0.x — mixed-typed config arrays and loosely-typed manifest reads are the usual friction points.