Websearch For Filament Laravel Package

Getting Started

1. Install the package with Composer (composer require <vendor/package>) and confirm the version constraint is pinned appropriately for a 0.x release.
2. If it is a Filament plugin, register it in your panel provider (->plugin(PackagePlugin::make())) and publish any config, migrations, or assets referenced in the README.
3. Start with the uninstaller in a disposable app before using it anywhere real:

   php artisan <package>:uninstall --help
   php artisan <package>:uninstall
   

   The default run should show what would be removed without dropping tables or editing composer.json.
4. Look first at the README banner/slogan for Filament directory compatibility, then at the service provider and the uninstaller command class to understand what the package registers and what cleanup it performs.
5. First real use case: test installation and removal in a scratch Laravel app so you know exactly which tables, config files, assets, and Composer entries a full uninstall touches.

Implementation Patterns

• Safe local cleanup: Run the uninstaller without flags first to inspect planned actions. Then, only on a disposable database, run with --drop-tables. Treat this as a development-only workflow.
• Full package removal from a project: Combine both flags deliberately:

  php artisan <package>:uninstall --drop-tables --remove-composer
  

  Commit the resulting composer.json / composer.lock changes and review the diff before pushing.
• CI and automation: Use --no-interaction when the command may run unattended. Because safe defaults are applied, CI will not silently drop tables or remove Composer dependencies unless you explicitly pass those flags.
• Filament panel integration: Register the plugin per panel as documented. Keep panel-specific configuration in config/<package>.php or the panel provider rather than editing vendor files.
• Version pinning: For 0.x, pin to ^0.1.1 or an exact version in composer.json, and read the release notes before every minor bump.
• Reuse the uninstaller pattern: If you maintain your own Laravel packages, the --drop-tables / --remove-composer / --no-interaction split is a useful template for destructive cleanup commands.

Gotchas and Tips

• --drop-tables is destructive and irreversible. Back up or use a disposable database. Confirm exactly which tables the command targets before running it against anything shared.
• --remove-composer modifies project files. It may edit composer.json and invoke Composer. Review the diff and ensure the lock file is updated and committed.
• --no-interaction means safe defaults, not “yes to everything.” It prevents prompts from blocking automation, but it will not opt you into destructive behavior. You still need explicit flags for table drops and Composer removal.
• Uninstallers rarely clean up everything. Published config, migrations, assets, and manually registered panel plugins may remain. Verify the application boots after uninstall and remove leftovers manually.
• Pre-1.0 instability: v0.1.1 is early. Expect command signatures, flags, and Filament integration details to change. Pin versions and check release notes before upgrading.
• Debugging: Run the uninstall command with verbose output (-v) and inspect both the database schema and composer.json afterward. If the command fails partway, cleanup may be incomplete.
• Extension points: Review the uninstaller command class for confirmation prompts, dry-run behavior, and any events or hooks before wrapping it in your own scripts. Avoid depending on undocumented internals in a 0.x release.