Download the PHP package coringawc/filament-plugin-workbench without Composer

On this page you can find all versions of the php package coringawc/filament-plugin-workbench. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of coringawc/filament-plugin-workbench

Informations about the package filament-plugin-workbench

filament-plugin-workbench

Shared development environment infrastructure for FilamentPHP plugins.

Provides:

Only prerequisite: Docker installed. No PHP, Composer, or Node required on the host.

Installation

Via git submodule (recommended)

Requires only git and docker.

When running workbench up, the script:

Via Composer

Use when the plugin already has Composer as its primary workflow.

Note: running workbench up or workbench install automatically adds the bootstrap:workbench, serve, and fresh:workbench scripts to the plugin's composer.json if they are not already present.

File permissions

The container runs as a non-root user (workbench) with the same UID/GID as the host user — so files created inside the container (screenshots, test results, generated code) are owned by your host user with no sudo needed.

The default UID/GID is 1000. If your host user has a different UID (run id -u to check), create a .env file in the plugin root before the first workbench up:

These values are read by docker-compose.yml and passed as build arguments to the image. If you skip this step on a non-1000 host and find that generated files are owned by the wrong user, remove the existing image and volume, add the .env, and run workbench up again:

The generated docker-compose.yml also injects DB_DATABASE with a persistent SQLite path inside the container by default:

This avoids Testbench falling back to the testing in-memory connection during HTTP requests handled by vendor/bin/testbench serve.

Available commands

Command Description
workbench up Copy templates if needed, verify providers, inject scripts, start container, follow logs
workbench up -d Same as up, but starts in detached mode (does not block the terminal)
workbench install Copy templates, fill providers, inject scripts into composer.json (no container start)
workbench install --force Same as install, overwrites existing files without prompting
workbench down Stop and remove the container
workbench fresh Run migrate:fresh --seed inside the container
workbench logs Follow container logs in real time
workbench shell Open an interactive shell inside the container
workbench help Show help

sail — Day-to-Day Development CLI

While workbench handles environment lifecycle (up/down/install), sail is a Sail-like proxy for running commands inside the already-running container. Available at vendor/bin/sail when installed via Composer.

Usage

Commands

Command Description
sail artisan <cmd> Run a testbench artisan command
sail phpunit [args] / sail test Run PHPUnit tests
sail phpstan [args] Run PHPStan analysis
sail pint [args] / sail lint Run Laravel Pint
sail rector [args] Run Rector
sail composer [args] Run Composer
sail php [args] Run PHP directly
sail node [args] Run Node.js
sail npm [args] Run npm
sail shell Open a bash shell in the container
sail up Start the Docker containers
sail down Stop the Docker containers
sail build Build the Docker containers
sail logs Tail container logs
sail <anything> Passed through to docker compose exec

Examples

Generating documentation screenshots

The workbench environment is pre-configured for Playwright screenshot generation. The PHP image includes all Chromium system libraries, and the Playwright browser binary is installed automatically on first container start when @playwright/test is listed as a dependency in the plugin's package.json.

Setup

Add @playwright/test to the plugin's package.json:

Create workbench/tmp-screenshots.spec.js with your Playwright test. On the next container start, the Chromium browser is downloaded to the playwright-browsers Docker volume — subsequent starts skip the download.

Running screenshots

How it works

Adding to a new plugin

The script automatically detects ServiceProviders declared in composer.json (extra.laravel.providers) and fills the generated testbench.yaml.

The scripts bootstrap:workbench, serve, and fresh:workbench are automatically added to the plugin's composer.json by workbench up or workbench install if they are missing.

The generated docker-compose.yml also includes a default persistent SQLite path for the Testbench skeleton database so that workbench up produces a container-ready environment without extra manual configuration.

After that, the plugin structure will look like:

What belongs where

File / Folder Location Why
Dockerfile, entrypoint.sh This package (packages/workbench/docker/) Generic, reusable infrastructure
stubs/docker-compose.yml.stub This package Template with build.context placeholder (resolved at copy)
stubs/testbench.yaml.stub This package Template with common variables documented
bin/workbench This package Bootstrapping CLI
bin/sail This package Sail-like development proxy CLI
workbench/ In the plugin Plugin-specific models, seeders, policies, resources, etc.
composer.json In the plugin Scripts bootstrap:workbench, serve, fresh:workbench
testbench.yaml In the plugin Plugin-specific providers and env
docker-compose.yml In the plugin Generated by workbench up — can be customised

Updating to the latest version

Via git submodule

Via Composer

Package structure

All versions of filament-plugin-workbench with dependencies

PHP Build Version
Package Version
Requires orchestra/testbench Version ^10.0
orchestra/workbench Version ^10.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package coringawc/filament-plugin-workbench contains the following files

Loading the files please wait ...