Struct Laravel Package

Product Decisions This Supports

• Feature/DTO strategy: Informs whether to use a lightweight annotated struct library for DTOs, request/response payloads, config objects, and internal domain structures instead of hand-rolled arrays or custom value objects.
• Build vs buy: Supports a build-vs-buy comparison against native PHP 8+ readonly classes, typed properties, constructor promotion, and Laravel features such as casts and validation. This package may reduce boilerplate, but its pre-1.0 API churn adds maintenance cost.
• Roadmap timing: The 0.3.0 release is a compatibility/cleanup release with a BC break—not a feature release. Adoption should be deferred until the API stabilizes or until a specific performance-sensitive use case is proven.
• Performance-sensitive hydration: The claimed 50x faster struct creation on PHP 7.1 vs PHP 5.6 supports a benchmark spike if high-volume object/struct creation is a known bottleneck. This is not sufficient justification on its own, especially because the comparison baseline is PHP 5.6.
• Legacy/modernization decisions: The release references PHP 5.6 and PHP 7.1 compatibility, which is a warning sign for modern Laravel applications requiring PHP 8.1+. It supports a decision to avoid this dependency unless compatibility with the current runtime is explicitly verified.

When to Consider This Package

Consider it when:

• The team needs simple, annotation-driven typed structures and does not need a full DTO/validation/serialization framework.
• The application can pin the dependency, wrap it behind an internal abstraction, and absorb BC breaks during the pre-1.0 period.
• A benchmark confirms struct creation is a meaningful bottleneck in the application.
• The project is on a PHP version explicitly supported by the package and the team has verified compatibility with its Laravel version.
• The migration from Int/String to Integer/Str is understood and all existing annotations/properties can be updated.

Look elsewhere when:

• The application is on modern Laravel/PHP 8+ and native readonly classes, typed properties, enums, and constructor promotion already cover the use case.
• The team requires semantic-versioning stability, long-term support, active maintenance, or a predictable upgrade path.
• The need includes validation, transformation, serialization, request mapping, or Eloquent integration—mature DTO packages are a better fit.
• Laravel framework integration is required; this package appears to be a standalone PHP dependency, not a Laravel-native solution.
• The 50x performance claim is the primary adoption driver without an application-specific benchmark.

How to Pitch It (Stakeholders)

For executives: This is a small PHP struct library. Release 0.3.0 contains no new functionality—it cleans up compatibility and introduces a breaking rename (Int to Integer, String to Str) because the old names are invalid in PHP 7. It also reports significantly faster struct creation on PHP 7.1 compared with PHP 5.6. The library is still pre-1.0, so adopting it now carries API-churn and maintenance risk. Recommendation: do not make it a strategic dependency; permit only a limited pilot if a concrete need for lightweight typed structures is proven, and otherwise rely on native PHP/Laravel capabilities or a more mature DTO package.

For engineering: Treat 0.3.0 as a migration release, not an upgrade with new capabilities. Any existing use of Int or String properties and annotations must be renamed to Integer and Str. Verify runtime compatibility with our current PHP and Laravel versions before adoption—the release notes frame compatibility around PHP 5.6/7.1, while modern Laravel requires PHP 8.1+. Re-run performance benchmarks in our environment rather than relying on the 50x claim, which is relative to PHP 5.6. If adopted, pin the version and isolate usage behind an internal interface to reduce future BC-break impact.