- How do I get started with filament-plugin-workbench in my Filament plugin project?
- Add the package as a git submodule with `git submodule add https://github.com/CoringaWc/filament-plugin-workbench.git packages/workbench`, then run `./packages/workbench/bin/workbench up`. This copies templates for `docker-compose.yml` and `testbench.yaml`, auto-detects providers from your `composer.json`, and starts the container with PHP 8.4, Node 22, and Composer 2 pre-installed.
- Does this work with Laravel 10 or Filament 3.x? Will it support future versions?
- The package is built for modern Laravel/Filament stacks and uses PHP 8.4/Node 22/Composer 2, which aligns with Laravel 10+. While it’s not explicitly version-locked, the author plans to update Docker images for Laravel 11+ and Filament 3.x. Check the GitHub repo for versioned image tags.
- Can I use this for non-Filament Laravel packages? Or is it Filament-specific?
- It’s optimized for Filament plugins (auto-injects `extra.laravel.providers` into `testbench.yaml` and includes Playwright), but the core Docker setup works for any Laravel package needing isolated PHP/Node environments. For non-Filament projects, you’d manually configure `testbench.yaml` or skip it.
- What if I need custom PHP extensions (e.g., `pdo_pgsql`) or a non-standard Docker setup?
- The package hardcodes a few extensions (like `intl`, `pcntl`) but doesn’t support custom `Dockerfile` overrides. For advanced needs, you’d need to extend the `docker-compose.yml` manually after installation. The author recommends opening an issue if you hit limitations.
- How does the `workbench` CLI differ from Laravel Sail? Is it lighter?
- Yes—it’s a stripped-down, Sail-like CLI focused on Filament plugin workflows. It lacks Sail’s full Laravel features (e.g., queue workers, Horizon) but includes `artisan`, `phpunit`, `phpstan`, and `pint` proxied into the container. It’s ~20MB lighter due to no Chromium unless Playwright is used.
- Will this work on Windows (non-WSL) or macOS Apple Silicon? Any known issues?
- Docker handles cross-platform compatibility, but the package assumes POSIX-compliant shells (no Bashisms). On Windows, use WSL or Docker Desktop. Apple Silicon users should verify volume permissions for `/tmp/.cache/ms-playwright`—the package pre-creates this to avoid issues.
- How does the auto-generated `testbench.yaml` handle edge cases like missing providers?
- The `workbench up` command validates `composer.json` for providers and scripts before generating `testbench.yaml`. If providers are missing or malformed, it throws a clear error. For custom providers, manually edit the file or extend the template stubs in the submodule.
- Do I need to install PHP/Composer/Node on my host machine?
- No—the entire stack runs in Docker. The only host requirement is Docker (and `git` for the submodule method). The container auto-installs dependencies on startup, so you never interact with host tools.
- What’s the performance impact of the Chromium libraries in the Docker image?
- The ~20MB Chromium addition is only for Playwright. If your plugin doesn’t use browser testing, the overhead is negligible. For lightweight plugins, you can skip Playwright entirely by removing related `composer.json` scripts.
- How do I contribute or report issues if the package isn’t maintained long-term?
- Open an issue or PR on GitHub. The MIT license allows forks, and the author encourages community adoption. For critical maintenance gaps, consider sponsoring the package or proposing it to the Filament team for official integration.