Getting Started
Treat v0.0.1 as an initial preview release. The published changelog only links to the commit history, so verify the README and source before relying on specific features.
Minimal setup:
- Install with Composer using the package name and version constraint from Packagist:
composer require tomatophp/filament-developer-tools:^0.0.1
- Publish any package config/assets only if the README instructs it:
php artisan vendor:publish --tag=filament-developer-tools-config
- Register the package’s Filament plugin in your admin panel provider, using the plugin class documented by the package.
- Restrict access before first use. Do not enable developer tooling on a public production panel.
- Run Filament’s asset/optimization commands as needed:
php artisan filament:assets
php artisan optimize:clear
Where to look first:
- The package README and
composer.json for Laravel/Filament/PHP constraints.
- The service provider for config publishing, migrations, routes, and Filament plugin registration.
config/filament-developer-tools.php if published.
- Filament pages/resources under
src/Filament or equivalent.
- Existing policies, gates, and panel access rules before exposing the tool.
First practical use case: add the tools to a local or staging admin panel where developers can inspect logs, routes, commands, cache state, or other diagnostics without needing SSH. Gate it to a super-admin role and a non-production environment.
Implementation Patterns
Use a dedicated developer panel when possible:
->plugin(\TomatoPHP\FilamentDeveloperTools\FilamentDeveloperToolsPlugin::make())
Keep the exact plugin class and registration syntax aligned with the package README, since v0.0.1 does not include detailed release notes.
Common day-to-day patterns:
- Environment-gated diagnostics: Enable only in
local and selected staging environments. Use an env flag such as DEVELOPER_TOOLS_ENABLED=false by default.
- Role-gated access: Require authentication plus a
super_admin or equivalent gate. Prefer panel access restrictions over hiding navigation items only.
- Safe command execution: If the package exposes Artisan or shell-like actions, allowlist safe commands and require confirmation for cache clears, migrations, queue restarts, and destructive operations.
- Log and route inspection: Use the panel for quick debugging during development, but keep long-term observability in your normal logging/monitoring stack.
- Deployment workflow: Install and publish only in non-production, or conditionally register the plugin based on environment. Rebuild Filament assets after upgrades.
- Audit trail: Log who accessed developer tools and which actions they performed, especially on shared staging environments.
- Config-driven restrictions: Put allowed environments, roles, commands, and paths in config rather than hard-coding them in panel providers.
Suggested production guard:
if (app()->environment('local', 'staging')) {
$panel->plugin(/* developer tools plugin */);
}
Then add a policy or canAccessPanel() check so even staging access is limited to trusted developers.
Gotchas and Tips
- Very early release:
v0.0.1 should be pinned exactly or with a tight constraint until the package stabilizes.
- Sparse release notes: The changelog only points to commits. Review the repository history and README before upgrading or assuming feature behavior.
- Never expose publicly: Developer tools can reveal environment variables, logs, routes, database structure, and command output. Treat them as privileged admin functionality.
- Check Filament compatibility: Confirm the package supports your Filament major version. Filament plugin APIs and asset registration changed across versions.
- Verify migrations: If the package ships migrations, review them before running on shared databases. Do not run unknown migrations directly on production.
- Clear caches after config changes: Filament and Laravel cache panel metadata, config, routes, and views. Use
php artisan optimize:clear and php artisan filament:optimize-clear when behavior seems stale.
- Authorization is not navigation hiding: Hiding a page from navigation does not secure it. Enforce access through panel access, policies, gates, or middleware.
- Debug registration issues: Check the panel provider, service provider discovery, Composer autoload, and
php artisan route:list / php artisan about. Confirm the plugin is registered on the intended panel only.
- Extension points: Use package config, policies, custom Filament pages, and panel middleware where available, but verify actual extension points in source before depending on them.
- Upgrade discipline: Because this is
v0.0.x, re-read the README and diff the package after every update. Expect possible breaking changes even if patch-level versioning suggests otherwise.