- What is asciito/filament-plugin-cli and what does it do?
- asciito/filament-plugin-cli is a Composer-installed CLI tool that scaffolds Filament plugin boilerplate for Laravel projects. It generates the directory structure, service providers, config, migrations and asset-registration wiring so you can move from an idea to a working plugin skeleton without manual setup. It is intended as a development and build-time tool, invoked by a developer or a CI job rather than by the application at runtime.
- How do I install asciito/filament-plugin-cli in a Laravel project?
- Install it as a dev dependency with composer require --dev asciito/filament-plugin-cli, then invoke the scaffolding command from your project root. Because it is a require-dev package it never ships to production. Pin an exact version such as 0.0.19 rather than a caret range, since the 0.0.x line carries no API stability guarantee.
- Does filament-plugin-cli add any runtime overhead or production risk?
- No. The package has zero runtime footprint: it registers no service provider behavior that persists at boot and publishes no config that the application consumes. The files it produces are ordinary source files you review and commit to your repository. Removal is composer remove --dev plus a quick check that no generated artifacts were left behind.
- Which Filament version does the generated code target, v3 or v4?
- The stubs target a specific Filament major, and v3 versus v4 scaffolding conventions differ materially, but the package does not clearly document which major its templates emit. Confirm this before accepting any scaffold. A tool that generates code for the wrong Filament major is worse than no tool, because the mismatch only surfaces after you review and commit the files.
- Which Laravel and PHP versions does it support?
- The PHP version floor and Laravel constraints are not clearly documented, so read the package's composer.json for the actual requirements. Verify that whatever it declares matches your application's Laravel major and PHP version before installing. Also check whether the project's CI matrix tests against those versions, since an unverified support claim is not a guarantee.
- Is the command idempotent, and what happens if I re-run it over an existing plugin?
- Idempotency is not documented and should be treated as unproven. The package performs regex-driven mutation of existing files, so re-running it over an already-scaffolded plugin directory could corrupt provider or config files. Run it in a throwaway branch, commit everything beforehand, and inspect the diff before accepting the output.
- What does the tag removal behavior change in my provider and config files?
- Tag removal refers to regex-based stripping or rewriting of marker tags inside existing provider, config or bootstrap files, rather than only generating fresh files. Releases v0.0.17 through v0.0.19 contained two separate fixes to the same regex, which suggests the logic is still converging rather than stabilized. That is the main reason to treat the tool as experimental and to review the diff before it is applied.
- Can I customize the generated stubs and boilerplate?
- Stub customization is not documented, and the templates appear to be hardcoded in the package. If your team's conventions differ from the emitted boilerplate you will likely need to fork the package or post-process the generated files. Check the repository for a publishable stub path before assuming you can override templates through configuration.
- Is the package stable enough for team use, and should I pin the version?
- It is pre-1.0 on a 0.0.x version line with no API stability guarantee, appears to be single-maintainer, and recently needed consecutive regex patches, so treat it as experimental. Pin an exact version so regex-behavior changes cannot arrive silently during a routine composer update. Adopt it as a developer-workstation convenience only, never as a production dependency or a deploy-time step.
- How should I evaluate filament-plugin-cli before adopting it?
- Spike it for about half a day: install on a throwaway branch, generate a plugin, hand-review every produced file, and git diff the result against a manually scaffolded equivalent. Specifically exercise the tag-removal path by regenerating over an existing plugin directory to confirm re-runs do not corrupt provider or config files. If the output does not match your installed Filament major or the diff is noisy, manual scaffolding or a minimal fork is the safer alternative.