Weave Code
Code Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Filament Plugin Workbench Laravel Package

coringawc/filament-plugin-workbench

Docker-based dev workbench for FilamentPHP plugin authors. Includes a generic PHP 8.4/Node 22/Composer 2 image, auto-install entrypoint, docker-compose and testbench templates, and a workbench/sail CLI to run artisan, tests, and tooling without local PHP/Node.

View on GitHub
Deep Wiki
Context7

Getting Started

Minimal Setup

  1. Add as a Git Submodule:

    git submodule add https://github.com/CoringaWc/filament-plugin-workbench.git packages/workbench
    
  2. Initialize Workbench:

    ./vendor/bin/workbench up
    
    • This copies docker-compose.yml.stub and testbench.yaml.stub to your plugin root.
    • Resolves the build.context dynamically to point to the Dockerfile in the submodule.
  3. Start Development:

    ./vendor/bin/sail artisan serve
    
    • Access your plugin at http://localhost:8001 (default port in stub).

First Use Case

  • Run Tests:
    ./vendor/bin/sail test
    
  • Run Linting:
    ./vendor/bin/sail lint
    
  • Open Shell:
    ./vendor/bin/sail shell
    

Implementation Patterns

Workflow Integration

  1. Plugin Development Loop:

    # Start environment (detached)
    ./vendor/bin/workbench up -d
    
    # Run tests in watch mode
    ./vendor/bin/sail test --watch
    
    # Serve the plugin
    ./vendor/bin/sail artisan serve
    
  2. Fresh Environment:

    ./vendor/bin/workbench fresh  # Migrate + seed
    
  3. Debugging:

    ./vendor/bin/workbench logs   # Tail container logs
    ./vendor/bin/sail shell       # Interactive shell
    

Key Patterns

  • Docker Context Resolution: The build.context in docker-compose.yml is dynamically replaced with the path to the submodule's Dockerfile (packages/workbench/docker/php). Use _fix_docker_context() to handle this during workbench up.

  • Provider Auto-Injection: The testbench.yaml stub includes a placeholder (# - Vendor\YourPlugin\...). Run ./vendor/bin/workbench up to auto-fill providers from composer.json under extra.laravel.providers.

  • Composer Scripts: The composer.json stub injects scripts like bootstrap:workbench, serve, and fresh:workbench. These are auto-generated if missing.

  • Playwright Integration: If your plugin uses @playwright/test, the Docker image pre-installs Chromium in a named volume (playwright-browsers). No manual setup required—just include the dependency in package.json.

Integration Tips

  • Custom Dockerfile: Override the Dockerfile by extending the base image in your plugin’s docker-compose.yml:

    services:
      php:
        build:
          context: ./packages/workbench/docker/php
          dockerfile: Dockerfile.extends  # Your custom Dockerfile
    
  • Environment Variables: Use .env files in your plugin root. The stub includes comments for all available variables (e.g., DB_DATABASE, APP_URL).

  • Volume Mounts: Mount plugin directories explicitly in docker-compose.yml:

    volumes:
      - ./:/var/www/html:cached
      - ./vendor:/var/www/html/vendor:cached
    

Gotchas and Tips

Pitfalls

  1. POSIX Compliance:

    • bin/workbench is written in POSIX sh (no Bashisms like [[, arrays, or $BASH_SOURCE). Test with:
      sh -n ./vendor/bin/workbench
      
    • Avoid Bash-specific syntax in custom scripts if they interact with workbench.
  2. Docker Context Path:

    • If workbench up fails with build.context errors, manually verify the path in docker-compose.yml:
      ./vendor/bin/workbench up --force  # Overwrites stubs (use cautiously)
      
  3. Provider Mismatch:

    • If tests fail with ClassNotFoundException, ensure extra.laravel.providers in composer.json matches your plugin’s namespace. Run:
      ./vendor/bin/workbench up  # Re-injects providers
      
  4. Playwright Caching:

    • If Playwright tests fail with permission errors, ensure the playwright-browsers volume exists and is owned by the workbench user (handled automatically by the Dockerfile).
  5. Host Dependencies:

    • Never call php, composer, or node directly on the host. All commands must proxy through docker compose exec (e.g., ./vendor/bin/sail artisan).
  6. Symlink Resolution:

    • If ./vendor/bin/workbench or ./vendor/bin/sail fails, resolve symlinks manually:
      readlink -f ./vendor/bin/workbench
      

Debugging Tips

  1. Container Logs:

    ./vendor/bin/workbench logs
    
    • Look for errors in the php service logs.
  2. Shell Access:

    ./vendor/bin/sail shell
    
    • Inspect files, permissions, or run manual commands (e.g., composer dump-autoload).
  3. Docker Compose Validation:

    docker compose config
    
    • Validate your docker-compose.yml for syntax errors.
  4. Composer Cache:

    • Clear the Composer cache inside the container:
      ./vendor/bin/sail composer clear-cache
      

Extension Points

  1. Custom Dockerfile:

    • Extend the base image by creating Dockerfile.extends in your plugin root and referencing it in docker-compose.yml:
      build:
        context: ./packages/workbench/docker/php
        dockerfile: Dockerfile.extends
      
  2. Custom Entrypoint:

    • Override entrypoint.sh by copying it to your plugin root and updating the command in docker-compose.yml:
      command: ["/var/www/html/entrypoint.sh"]
      
  3. Additional Services:

    • Extend docker-compose.yml to include databases, Redis, or other services:
      services:
        database:
          image: mysql:8.0
          environment:
            MYSQL_ROOT_PASSWORD: secret
            MYSQL_DATABASE: plugin_db
      
  4. Custom Workbench Commands:

    • Add subcommands to bin/workbench (POSIX sh) or bin/sail (Bash) following the subcommand reference. Example:
      # In bin/workbench
      cmd_migrate() {
        docker compose exec php php artisan migrate
      }
      
      Add to the case block:
      migrate) cmd_migrate "$@";;
      

Configuration Quirks

  1. Testbench Database:

    • The stub sets DB_DATABASE to /var/www/html/vendor/orchestra/testbench-core/laravel/database/database.sqlite by default. For HTTP requests, this avoids Testbench’s in-memory :memory: database. Override in .env if needed:
      DB_DATABASE=mysql
      
  2. Provider Auto-Fill:

    • If _ensure_providers() fails silently, check:
      • extra.laravel.providers exists in composer.json.
      • The placeholder # - Vendor\YourPlugin\... is present in testbench.yaml.
  3. Volume Ownership:

    • If you encounter permission errors in /tmp/.cache/ms-playwright, ensure the Dockerfile pre-creates the directory with the correct ownership (handled automatically in the base image).

Performance Tips

  1. Layer Caching:

    • The Dockerfile separates Chromium libraries into a dedicated RUN block to avoid cache invalidation for plugins not using Playwright.
  2. Composer Install:

    • The entrypoint.sh skips composer install if vendor/autoload.php exists, speeding up container restarts.
  3. Node Modules:

    • Similarly, npm install is skipped if node_modules/ exists, reducing rebuild time.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
terminal42/code-quality-tools
codifyo/ts-generator-bundle
andydefer/laravel-cluster
testo/fiber
mintobit/jobqueue
a4sex/maintenance-bundle
a4sex/entity-date-update
a4sex/client-identifier
a4sex/base-utilites
a4sex/key-value-storage
a4sex/micro-status
chilldev/dependency-injection-extra
datinglibre/datinglibre-app-api
biberltd/corebundle
bricre/symfony-bundle-test
biberltd/logbundle
dominium/http-adapter-bundle
dominium/google-analytics
a4sex/auto-clean-entity
christhompsontldr/laravel-inky