Data Grid Export Laravel Package

Product Decisions This Supports

• PHP 8 upgrade planning (primary): v4.1.0 adds PHP 8 support, which unblocks or de-risks migrating our Laravel services off PHP 7.x. This is the gating dependency for any roadmap item tied to framework/runtime modernization (security patching, performance, hosted-runtime EOL deadlines).
• Dependency risk review: an actively maintained package shipping runtime compatibility is a signal to keep it in the "maintained" column rather than scheduling a replacement. Re-evaluate any "build vs. buy" or "vendor out" spikes opened because of PHP 8 incompatibility.
• Build vs. buy: if this package is on the critical path of a launch, PHP 8 support may remove a blocker that would otherwise justify an in-house reimplementation — a reimplementation is usually far more expensive than waiting for a compatibility release.
• Roadmap sequencing: any feature work that requires PHP 8 (new framework majors, typed properties, constructor promotion, JIT-adjacent performance gains) can now be sequenced rather than deferred.
• Use cases: treat this release as an enabler, not a feature. Don't market it to customers; use it internally to close upgrade tickets and reduce technical-debt carry.

When to Consider This Package

Adopt or retain it when:

• You are on or moving to PHP 8.x and need Laravel dependencies that don't force --ignore-platform-reqs or composer update workarounds. v4.1.0 makes this package a viable dependency on modern runtimes.
• You are still on PHP 7.x — the minimum supported version is not documented in these release notes. Confirm whether 4.1.0 dropped PHP < 8 support before upgrading; a minor-version bump that only "adds" support should be non-breaking, but verify against composer.json constraints and the changelog rather than assuming.
• You value maintenance cadence: a compatibility release is evidence of an active maintainer, which is the single strongest predictor of long-term viability for a small package.
• You need a small, single-responsibility dependency rather than a framework-scale one — this package's scope is not described here, so validate fit against your own requirements before treating this assessment as an endorsement.

Look elsewhere when:

• The package's core functionality is duplicative of a first-party Laravel feature — first-party wins on upgrade-cycle risk.
• You need documented LTS guarantees or vendor SLAs; community packages rarely provide them.
• Your platform still requires PHP 7.x and this release turns out to be a major-version-equivalent break (confirm the constraints).
• The package has a single maintainer and sits on a revenue-critical path — that's a bus-factor risk independent of PHP 8 support.

How to Pitch It (Stakeholders)

To executives: A dependency our Laravel stack relies on has shipped PHP 8 support. That removes one of the blockers on our runtime upgrade, which is the prerequisite for staying on a supported, security-patched PHP version and avoiding end-of-life fire drills. No new spend, no new vendor — this is a maintenance release that lowers schedule risk on work we already planned.

To engineering: v4.1.0 adds PHP 8 support. Treat it as a compatibility unblock, not a feature change. Before upgrading, verify the new composer.json platform constraints to confirm whether PHP 7.x is still supported, run the test suite in CI against PHP 8, and check for transitive dependency conflicts. If the constraints narrowed to PHP 8-only, this is effectively a breaking change for any service still on 7.x and needs a staged rollout: pin the old major for lagging services, upgrade forward-looking services first, and track the remaining PHP 7.x services as explicit migration tickets.

Ask: schedule the upgrade in the next maintenance window, add PHP 8 to the CI matrix if it isn't already, and record this package as "no longer a PHP 8 blocker" so the runtime upgrade plan can proceed without further investigation here.