Canvas Laravel Package

Technical Evaluation

Architecture Fit

• Laravel-Centric Design: Canvas is architecturally aligned with Laravel’s core make: commands, making it a drop-in replacement for scaffolding needs. The package leverages Laravel’s stub-based generation system, ensuring consistency with existing Laravel applications and packages.

  • Pros: Seamless integration with Laravel’s ecosystem (e.g., Eloquent models, Artisan commands, migrations). Supports package development outside Laravel via canvas.yaml presets.
  • Cons: Limited to Laravel/PHP stacks; not suitable for non-Laravel PHP frameworks (e.g., Symfony, Lumen).

• Modularity: The package is modular by design, with clear separation between:

  • Core generation logic (orchestra/canvas-core).
  • Laravel-specific overrides (e.g., LaravelServiceProvider for Artisan command replacement).
  • Customizable stubs (YAML/preset-based configuration).
  • Impact: Easy to extend for project-specific needs (e.g., custom stubs, additional commands like make:job-middleware).

• Dependency Management:

  • Hard dependencies: orchestra/canvas-core, orchestra/sidekick, PHP 8.4+, Laravel 11/12/13.
  • Soft dependencies: laravel/sanctum (for user-model stubs), phpstan/phpstan.
  • Risk: Tight coupling with Orchestra’s ecosystem (e.g., sidekick for CLI tools). Potential for dependency bloat if not managed.

Integration Feasibility

• Laravel Applications:

  • Zero-config integration: Automatically replaces Artisan make: commands via LaravelServiceProvider (Package Discovery).
  • Manual override: Use composer exec canvas for non-Laravel environments (e.g., packages).
  • Feasibility: High—works out-of-the-box with Laravel 11+. Minimal setup required (canvas.yaml for customization).

• Laravel Packages:

  • Package-specific presets: Supports non-Laravel package development with configurable paths/namespaces (e.g., src/, resources/).
  • Feasibility: High—designed for this use case. Example:

    preset: package
    namespace: Acme\Auth
    paths:
      src: src
    

  • Caveat: Requires manual stub customization for package-specific logic (e.g., custom traits, interfaces).

• Monorepos/Multi-Package Projects:

  • Challenge: Shared canvas.yaml or per-package configs may conflict.
  • Solution: Use project-level canvas.yaml with dynamic namespace resolution or package-specific configs.
  • Feasibility: Medium—requires discipline in configuration management.

Technical Risk

Key Questions for TPM

1. Laravel Version Alignment:

   • What’s the target Laravel version for the project? Canvas supports 11/12/13 (as of 2026), but older versions may require backporting.
   • Example: If using Laravel 10, confirm compatibility or plan a version upgrade.

2. Customization Needs:

   • Does the team need project-specific stubs (e.g., custom traits, annotations)?
     • Action: Extend stubs in resources/stubs/ or override via canvas.yaml.
   • Are there non-Laravel package assets (e.g., Dockerfiles, frontend templates) that Canvas doesn’t cover?
     • Action: Combine with other tools (e.g., plates for PHP templates, make:file for generic files).

3. CI/CD Integration:

   • Should Canvas be used in CI pipelines for automated scaffolding (e.g., GitHub Actions)?
     • Example:

       # .github/workflows/scaffold.yml
       - run: composer exec canvas make:model Post --migration --factory
       

   • Risk: Overuse may lead to flaky pipelines if stubs change unexpectedly.

4. Team Adoption:

   • How will the team standardize canvas.yaml across projects/packages?
     • Solution: Template files (e.g., templates/canvas.yaml) or enforce via pre-commit hooks.
   • Will developers prefer Canvas over Artisan for new files?
     • Strategy: Phase out Artisan make: commands in favor of Canvas for consistency.

5. Long-Term Maintenance:

   • Who will update stubs if Laravel’s core scaffolding changes (e.g., new PHP attributes)?
     • Action: Assign a tech lead to monitor Orchestra’s releases or fork Canvas for private maintenance.
   • How will package dependencies (e.g., orchestra/sidekick) be managed?
     • Action: Audit dependencies annually; consider vendoring critical components if needed.

6. Performance Impact:

   • Could frequent stub generation slow down local development?
     • Mitigation: Cache generated files or use lazy loading for non-critical stubs.

7. Security:

   • Are stubs vetted for security (e.g., no hardcoded secrets, safe file paths)?
     • Action: Review stub templates for vulnerabilities (e.g., file_put_contents usage).

Integration Approach

Stack Fit

• Primary Use Cases:

  • Laravel Applications: Replace Artisan make: commands with Canvas for consistent scaffolding.
  • Laravel Packages: Generate package-specific files (e.g., make:provider, make:command) outside a Laravel install.
  • Monorepos: Standardize scaffolding across multiple Laravel projects/packages via shared canvas.yaml.

• Stack Compatibility:

  Component	Compatibility	Notes
  Laravel 11/12/13	✅ Full support	Uses Laravel’s MigrationGeneratorCommand.
  PHP 8.4+	✅ Required	PHP 8.3 may work but unsupported.
  Composer	✅ Required	Installed as a dev dependency.
  Orchestra/Testbench	⚠️ Optional (for testing)	Only needed if testing packages.
  Custom Stubs	✅ Supported	Override via resources/stubs/.
  Non-Laravel PHP	❌ Not supported	Avoid for Symfony/Lumen projects.

• Integration Points:

  1. Artisan Command Override:
     • Canvas registers a LaravelServiceProvider that replaces Artisan’s make: commands.
     • Example: php artisan make:model User → php artisan canvas:make:model User.
     • Note: Uses Package Discovery, so no manual service provider registration is needed.
  2. CLI Execution:
     • Run directly via vendor/bin/canvas or composer exec canvas.
     • Example:

       composer exec canvas make:controller API/UserController --api
       

  3. Preset Configuration:
     • Define canvas.yaml in the project root to customize:
       • Namespaces (e.g., App\Modules\Auth).
       • Paths (e.g., src/ for package sources).
       • Stub overrides.

Migration Path