Blueprint Macro Laravel Package

Product Decisions This Supports

• Build vs. buy on schema conventions: the package's value is not novel functionality but the maintenance of compatibility across framework and test-tooling versions. Adopting it converts a recurring internal chore (re-validating your migration helpers against each Laravel/PHPUnit/Pest release) into a versioned dependency you upgrade on your own cadence.
• Standardization of schema/migration code: if your product's migrations repeatedly express the same column patterns (identifiers, timestamps, soft deletes, ownership/audit columns, tenant scoping), Blueprint macros let you encode that once as a house style rather than copy-pasting it across hundreds of migration files. That is a codebase-health and onboarding decision more than a feature decision.
• Roadmap sequencing for framework upgrades: 5.4.0 adds Laravel 13 constraints, PHPUnit 12 compatibility, and Pest 4 support. Treat this as an upgrade-enabler: it clears a blocker on the Laravel 13 / PHP 8.4 upgrade path. If Laravel 13 is on your roadmap this half, this release is a prerequisite item, not a nice-to-have.
• Test-infrastructure decisions: PHPUnit 12 / Pest 4 support means the package does not pin your test stack. That matters if you're planning a Pest migration or a PHPUnit major bump — it removes a "we can't upgrade because a dependency blocks it" objection.
• Risk/portfolio hygiene: a dependency that ships same-cycle support for the current Laravel major is a low-maintenance line item. A dependency that lags is a future forced-migration cost. This release is evidence for the former.

When to Consider This Package

Adopt when:

• You maintain more than a handful of migrations and have an emerging (or explicit) convention for common columns — the payoff comes from repetition, not from a single table.
• You are on or moving to a recent Laravel major (this release targets Laravel 13, with CI on Laravel 12 / PHP 8.3–8.4) and want dependencies that don't block the upgrade.
• Your team is willing to treat the macro layer as shared infrastructure: documented, reviewed, and versioned, not a place for one-off per-developer shortcuts.
• You want the compatibility matrix maintained for you — the real cost being absorbed here is the Laravel/PHPUnit/Pest support treadmill, plus static analysis (larastan/phpstan) and tooling upkeep.
• You are standardizing test tooling (Pest 4 or PHPUnit 12) and need your dependency graph to be neutral on that choice.

Look elsewhere when:

• You have few migrations or a young schema — the abstraction cost exceeds the duplication it removes.
• Your team values fully explicit, self-contained migration files; indirection through macros hurts readability and greppability for new hires and auditors.
• You need cross-database portability guarantees or schema linting/generation — this is a thin macro layer, not a schema tooling suite; evaluate dedicated migration-linting or generator tooling instead.
• You are on an older Laravel major and can't take the current constraint set — confirm constraint ranges before adopting, since the release notes describe the newer end of the matrix (Laravel 12 CI, Laravel 13 constraints).
• The macros you'd actually use are two or three lines each and stable — in that case vendoring a small internal trait is lower-risk than a dependency.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-risk dependency update, not a new product capability. The 5.4.0 release is a maintenance release: it adds Laravel 13 support and brings the package's test tooling current (PHPUnit 12, Pest 4), with no breaking changes to how we use it. The practical effect is that it unblocks our Laravel 13 upgrade path and removes a future forced-migration item from the backlog. It carries no user-facing change, no data risk, and no licensing or vendor cost. The decision required is simply whether to keep our migration conventions on a maintained external package or absorb that upkeep internally — and this release is evidence the package is being actively maintained.

For engineering (summary): 5.4.0 widens illuminate/* constraints to include ^13.0, adds PHPUnit 12 compatibility and Pest 4 support, updates phpunit.xml.dist, standardizes CI on Laravel 12 with PHP 8.3/8.4, and refreshes dev dependencies (larastan, phpstan plugins, collision). No functional or API changes, no deprecations, no breaking changes — the diff is entirely constraint and tooling maintenance. Engineering action: bump the dependency, confirm the resolved illuminate/* and test-tooling versions match our target matrix, and run the existing suite. If we adopt the macros as a house convention, the follow-on work is documenting the macro set and enforcing it in review — that's the actual cost, and it's ours to scope, not the package's.