Laravel Patches Laravel Package

Product Decisions This Supports

• Data-change governance vs. raw migrations. This package gives ordered, recorded, reversible execution of one-off data patches (backfills, corrections, seed/fix-ups) on top of Laravel's migration conventions. The v4.1.0 rollback hardening is the decisive change: a failing down() now halts rollback, rethrows the original exception, and keeps the execution record, so a half-rolled-back batch can no longer be silently reported as clean. That makes rollback state an auditable, trustworthy signal — which is what turns this from "convenience wrapper" into something you can put in a production change process.
• Release/deploy risk decisions. Any product decision that ships a data fix into production (pricing corrections, entitlement backfills, schema-adjacent cleanups) can now be paired with a verified rollback path and a preserved record of what actually happened. Teams can define a policy: patches are the only sanctioned way to mutate production data outside migrations, and failed rollbacks block further deploys until corrected.
• Platform upgrade sequencing (concrete roadmap input). Laravel 13 is supported, but Laravel 13 requires PHP 8.3+, and the maintainers explicitly flag Laravel 11 as out of security support with unresolved upstream advisories, recommending patched Laravel 12.69+/13.30+ for production. This is a direct input to the platform-upgrade roadmap: if this package is in the data-change path, the PHP 8.3 jump is now on the critical path for Laravel 13 adoption.
• Build vs. buy. The alternative is an in-house artisan command that reads a patches/ directory, writes rows to a patches table, and supports down(). That's a few days of build plus indefinite ownership of rollback semantics, concurrency edge cases, and framework-version churn. Buying (adopting) is defensible purely on the cost of getting the rollback-failure semantics right — v4.1.0 shows that detail is subtle enough to have shipped wrong previously.
• Incident-response readiness. Because failed rollbacks now preserve the execution record, runbooks can rely on "the record reflects reality" rather than reconstructing history from logs. Worth codifying in an on-call doc rather than leaving implicit.

When to Consider This Package

Adopt when:

• You repeatedly need ordered, one-off data changes in production (backfills, corrections, reference-data seeding) that must be version-controlled, auditable, and reversible alongside the deploy.
• You already think in migrations — the mental model and file layout transfer, so the learning cost is largely documentation, not training.
• You need rollback of data changes as a first-class operation, not a manual SQL script kept in a wiki. The stop_on_error / always-stop-on-rollback-failure split is a reasonable default and now behaves predictably.
• You're on (or moving to) Laravel 12.69+ or 13.30+ on PHP 8.3+ — the supported, security-clean configuration the maintainers point at.
• You want a small, single-purpose dependency with a real test suite behind it (154 tests / 403 assertions, matrix validated on the merged commit and the release tag, not just the PR).

Look elsewhere or wait when:

• Your need is schema changes — use Laravel migrations; don't layer this on top.
• You're doing bulk/streaming data movement, ETL, or scheduled transformations — that's a job/pipeline concern (queues, dedicated tooling), not patch execution.
• You're on Laravel 11: it still installs, but it's outside security support with unresolved upstream advisories. Treat this as a blocker for production adoption decisions, not a footnote — budget the PHP 8.3 / Laravel 12.69+ upgrade first.
• You expect the package to undo partial database changes made by a failed down(). It won't: preserving the execution record is bookkeeping, not compensation. If your patches aren't wrapped in transactions, you still own inconsistent-state recovery. If your team won't reliably write transactional down() methods, this package reduces but does not remove rollback risk.
• You need multi-node concurrency guarantees or orchestration across environments — verify against your deploy model before assuming.

How to Pitch It (Stakeholders)

To executives (one paragraph): We're evaluating a small Laravel package that makes production data changes auditable, ordered, and reversible using the same discipline we already apply to database migrations. The latest release adds support for the newest Laravel version and, more importantly, fixes a real safety gap: when a rollback fails, the system now stops and records the truth instead of reporting a false success. That directly reduces the risk and recovery time of the data fixes we ship — the kind of change that otherwise becomes a late-night manual SQL exercise. Cost is a small dependency and a process convention, not a build project; the alternative is an in-house tool we'd own forever. The main caveat is a platform dependency: full benefit assumes we're on a security-supported Laravel version and PHP 8.3+, so this ties into the upgrade work already on the roadmap.

To engineering (short): Single-purpose package for running ordered, recorded, reversible data patches — migrations semantics applied to data. v4.1.0 adds Laravel 13 support (PHP 8.3+ there; 8.2 still fine on 11/12), and fixes rollback failure handling: down() throwing now halts rollback, rethrows the original exception, and retains the patch execution record; completion/failure events carry the original batch. No new migrations when upgrading from 4.0.x. Two things we must own: (1) rollback does not compensate partial DB changes — wrap patches in transactions where that matters; (2) correct any failed rollback before retrying. Coverage is credible (154 tests / 403 assertions, matrix run on the tag, clean audits on 12/13). Proposed pilot: adopt for one non-critical backfill, codify the transaction and failed-rollback runbook, then make it the default path for production data fixes.