- What is lara-zeus/filament-plugin-tools used for?
- It is a Laravel developer package that provides practical utilities and scaffolding for building Filament plugins, covering common setup work such as service providers, config, assets, stubs and directory layout. The goal is to streamline repetitive plugin development tasks so you can stand up and manage plugins more efficiently inside Filament admin panels. It is developer tooling, not a runtime library that ships with your application.
- Should I install filament-plugin-tools with require-dev or require?
- Install it with require-dev. The package scaffolds plugin skeletons and never enters the request path, so it belongs in the DevEx and tooling budget line rather than your production requirements. Keeping it in dev also means failures surface in a developer branch or CI instead of production, and reversing the decision is a single composer remove --dev.
- Which Laravel and Filament versions does filament-plugin-tools support?
- The technical assessment describes it as an appropriate fit for a Laravel 10, 11 or 12 team running Filament v3, and flags as an open question whether 2.x is a maintained Filament v3 line while 3.x targets Filament v4. Because an explicit PHP, Laravel and Filament constraint matrix per release line was not documented in the material reviewed, inspect composer.json on the exact tag you intend to pin. Align its supported Filament major with the panel version you already run before standardizing.
- How do I install filament-plugin-tools in a Laravel application?
- Adoption is a composer require --dev plus, optionally, publishing the package's stubs and configuration. There is no data model, no migration and no coupling to application runtime beyond Filament's own panel registration. One engineer can validate it end to end in a spike branch within a day.
- Does filament-plugin-tools affect production performance or create runtime risk?
- No. It is developer tooling that scaffolds Filament plugin skeletons, so it is not loaded during requests and carries no latency exposure or customer-facing blast radius. Problems show up in a developer branch or CI rather than in production. The residual risk sits in release hygiene and dependency drift in your dev graph, not in production behavior.
- Do the generators produce tests and a CI-friendly plugin skeleton?
- The material reviewed does not confirm whether generated skeletons include a working test harness, and it explicitly lists this as an open question that changes the leverage calculation. Validate it on a real plugin with real surface area rather than a hello-world that only proves the generator runs. If tests and CI structure are missing, budget time to add them yourself.
- Why did version 2.0.5 remove illuminate/contracts, and will it break my app?
- Version 2.0.5 dropped illuminate/contracts, most likely because Filament supplies Contracts transitively, so real-world impact is probably small. The risk is for any consumer that relied on this package to pull Contracts into the dependency graph, which could now hit a class-not-found error. Whether the removal was genuine cleanup or a way to dodge a conflict with a specific Laravel release is unanswered, and if it was the latter the removal may regress in a later patch.
- Is filament-plugin-tools actively maintained, and should I standardize on the 2.x or 3.x line?
- Two things gate standardization rather than mere adoption: release provenance looks loose, with the 2.0.5 changelog comparing 3.0.0...2.0.5, and it is unclear whether 2.x is an actively maintained Filament v3 line while 3.x targets Filament v4. Both readings point to loose release hygiene and hurt your ability to reason about what to pin in a shared template. Check the observed release cadence over the last 12 months and prefer readable tagged diffs over compare links before committing either line.
- How risky is adopting filament-plugin-tools when it has few stars and dependents?
- With roughly four stars and zero dependents you would be an early adopter, so problems would be yours to discover. That does not disqualify it for dev tooling, but it does mean the pilot should be a real in-house plugin with real surface area instead of a toy. The profile is cheap to try and cheap to undo, which favors a time-boxed spike decision over a committee review.
- What are the alternatives to filament-plugin-tools for scaffolding Filament plugins?
- The baseline alternatives are Filament's own plugin skeleton generator and plain manual scaffolding, and both avoid adding a convention layer to code review. This package pays off when you have three or more in-house Filament plugins or a roadmap that implies them; for a single monolithic admin panel with no plugin strategy it is unused ceremony that still has to be upgraded. Compare candidates on whether they emit a working test harness and CI-friendly structure, since that is where the leverage actually is.