Millwright Util Laravel Package

Product Decisions This Supports

• Internal Tooling Standardization: Adopt a unified utility library to reduce code duplication across microservices or monolithic PHP/Laravel applications, improving maintainability and developer velocity.
• Dependency Management: Replace ad-hoc utility functions with a centralized, version-controlled package to simplify dependency updates and reduce technical debt.
• Laravel Ecosystem Integration: Leverage ContainerUtil for Symfony DI (Laravel’s core) to streamline service aggregation by tags (e.g., for plugins, middleware, or event listeners) and configuration merging, reducing boilerplate in service providers.
• Data Safety & Validation: Use PhpUtil for assertions, safe array cloning, and mergers to enforce consistency in APIs, forms, or data pipelines (e.g., preventing null/undefined issues in Laravel requests or Eloquent models).
• Date Handling: Standardize SQL date formatting across applications (e.g., for reporting, auditing, or database interactions) via DateUtil constants, reducing edge-case bugs.
• Build vs. Buy: Justify adopting this over rolling custom utilities or using bloated packages like Laravel Mix/Packages, given its niche focus and low overhead.
• Roadmap: Phase in utilities incrementally (e.g., start with ContainerUtil for a new plugin system, then expand to PhpUtil for API validation).

When to Consider This Package

• Avoid if:
  • Your team lacks PHP/Laravel expertise to integrate or maintain custom utilities (opt for Laravel’s built-in helpers or packages like spatie/laravel-array-to-object instead).
  • You need active community support (0 stars/dependents signals low adoption; consider nunomaduro/collision or spatie/laravel-package-tools for DI/service tagging).
  • Your use case requires advanced features (e.g., reactive programming, async utilities) beyond basic assertions/container helpers.
  • You’re using non-Symfony DI (e.g., pure Laravel Facades) and don’t need container tag aggregation.
• Look elsewhere if:
  • You prioritize batteries-included solutions (e.g., laravel-ide-helper for static analysis or spatie/laravel-query-builder for complex date handling).
  • Your stack is non-PHP (e.g., Node.js, Python) or uses alternative frameworks (e.g., Symfony standalone).
  • You need enterprise-grade support (e.g., for compliance/auditing; this package lacks documentation/maturity).

How to Pitch It (Stakeholders)

For Executives: "This lightweight PHP utility library helps us reduce technical debt by consolidating common code (e.g., service management, data validation) into a reusable package. For example, it lets our Laravel apps aggregate services by tags—like plugins or middleware—without manual configuration, cutting development time by ~20% on new features. It’s a low-risk ‘build vs. buy’ win: minimal maintenance overhead, no vendor lock-in, and immediate ROI for teams already using PHP/Laravel."

For Engineering: *"MillwrightUtil gives us three key tools:

1. ContainerUtil: Tag-based service aggregation (e.g., for dynamic middleware or event listeners) with zero boilerplate—replaces repetitive bindTagged() calls in Laravel service providers.
2. PhpUtil: Safe array cloning/merging and assertions to prevent runtime errors (e.g., in API payloads or form data).
3. DateUtil: SQL date constants to avoid magic strings in queries. Pros: Tiny footprint, no external dependencies, and aligns with our Symfony DI stack. Cons: Underdocumented (we’d need to write internal guides). Let’s pilot it for our [X] service’s plugin system first."*