Meta Laravel Package

Product Decisions This Supports

• Accelerate Laravel Package Development: Reduces boilerplate for common package concerns (migrations, scheduling, middleware, etc.), enabling faster iteration and consistent implementation across internal/external packages.
• Standardize Package Architecture: Enforces best practices (e.g., publishable migrations, Octane compatibility) to align with Laravel’s evolving ecosystem, reducing technical debt.
• Build vs. Buy Decision: Justifies building this into core package infrastructure instead of piecemeal solutions (e.g., custom traits or third-party tools) by offering a unified, maintained solution.
• Roadmap for Package Ecosystem:
  • Phase 1: Adopt for new packages to reduce onboarding time.
  • Phase 2: Retrofit into existing packages to modernize their architecture.
  • Phase 3: Extend with custom helpers (e.g., withGate(), withPolicy()) for auth-related packages.
• Use Cases:
  • Internal Tools: Rapidly develop reusable Laravel packages (e.g., payment processors, reporting tools).
  • Open-Source Contributions: Maintain consistency with Laravel’s standards for community packages.
  • Enterprise Packages: Ensure scalability and Octane compatibility for high-traffic applications.

When to Consider This Package

• Adopt When:

  • Building new Laravel packages (v12+) requiring migrations, scheduling, or middleware.
  • Maintaining multiple packages and needing consistent boilerplate reduction.
  • Prioritizing developer velocity over minimalism (e.g., teams with tight deadlines).
  • Targeting Laravel Octane or PHP 8.3+ environments.
  • Requiring attribute reflection (e.g., custom validation, metadata handling).

• Look Elsewhere If:

  • Using Laravel <12 or PHP <8.3 (compatibility gaps).
  • Packages are minimalist (e.g., single-file utilities) where helpers add unnecessary abstraction.
  • Preferring manual control over fluent interfaces (e.g., custom middleware registration logic).
  • Already using a mature alternative (e.g., Spatie’s package tools) with deeper ecosystem integration.
  • Testing-focused needs exceed core functionality (e.g., advanced mocking; consider laragear/meta-testing separately).

How to Pitch It (Stakeholders)

For Executives:

"This package cuts 30–50% of boilerplate code in Laravel packages—saving dev time and reducing bugs. By standardizing migrations, middleware, and scheduling, we ensure our internal tools (e.g., [Package X]) ship faster and align with Laravel’s latest standards. It’s a low-risk, high-reward investment for scaling our package ecosystem, with MIT licensing and Octane compatibility for future-proofing."

Key Metrics to Track:

• Dev velocity: Time saved per package (e.g., "Reduced migration setup from 2 hours to 15 minutes").
• Consistency: Fewer architectural drift issues across packages.
• Maintenance: Reduced tech debt from repetitive patterns.

For Engineering Teams:

*"laragear/meta gives you fluent, expressive helpers to handle the tedious parts of Laravel packages—no more rewriting the same boot() logic. Key benefits:

• Migrations: Publish and register them in one line (withPublishableMigrations()).
• Middleware: Declaratively set priorities, aliases, or groups (MiddlewareDeclaration).
• Testing: Built-in assertions for migrations, validation, and auth (via meta-testing).
• Octane-Ready: No stale singletons or request instances—future-proof for high-performance apps.

Example:

// Before (boilerplate):
$this->loadMigrationsFrom(__DIR__.'/../migrations');
$this->app->make('schedule')->command('report:generate')->daily();

// After (concise):
$this->withPublishableMigrations(__DIR__.'/../migrations');
$this->withSchedule(fn($schedule) => $schedule->command('report:generate')->daily());

Why now?

• Laravel 12+ and PHP 8.3+ are our targets.
• Aligns with our push for modular, maintainable packages.
• MIT license = no vendor lock-in.

Next Steps:

1. Pilot in [Package Y] to validate time savings.
2. Document patterns for the team (e.g., ‘Always use withMiddleware() for global middleware’).
3. Explore extending for custom use cases (e.g., attribute-based validation)."*

Call to Action:

• Engineering: "Let’s adopt this for [Package A] and [Package B] in the next sprint."
• Product: "Prioritize packages where this will save the most time (e.g., [high-maintenance Package C])."
• Tech Lead: "Review the Octane compatibility section to confirm no conflicts with our stack."