Data Grid Export Laravel Package

Getting Started

What changed: v4.1.0 (published 2020-12-23) adds PHP 8 support. That is the entire changelog. Context matters here: PHP 8.0.0 went GA on 2020-11-26, so this tag landed roughly four weeks later. It is a fast-follow compatibility release — the package maintainer chasing the new runtime, not shipping behaviour. Treat it as "the package now runs on PHP 8.0" and nothing more. It cannot have been tested against PHP 8.1+, which did not exist yet.

First steps before you composer require:

1. Read composer.json and look at the require.php constraint and the CI matrix (.travis.yml / .github/workflows). Two different facts: the constraint is what Composer enforces; the matrix is what the maintainer actually ran. "Add PHP 8 support" sometimes means the constraint was widened to ^7.x || ^8.0, and sometimes means it was already permissive (>=7.2) and this release is just test-suite and deprecation cleanup. Read both.
2. Check whether the package declares a service provider with auto-discovery and whether it ships a publishable config (php artisan vendor:publish). Those two facts determine your entire integration surface.
3. Check the README for a Laravel version matrix. PHP 8 support says nothing about framework compatibility, and in December 2020 that cut is sharper than usual: Laravel's own PHP 8 support was still landing in 8.x patch releases through this period. Your laravel/framework version may be the actual blocker, not this package. Verify against your lock file before you blame the package.

First use case: on a single non-critical route or queued job, install v4.1.0 on a PHP 8.0.x runtime and exercise the package's primary code path once — one real call through your app, not the package's own test suite. If output is identical to what you get on PHP 7.4 with 4.0.x, the migration is a no-op and you can widen the rollout.

Upgrade path: from 4.0.x this is a minor bump and should be constraint-compatible. Pin ^4.1, run composer update vendor/package, then composer dump-autoload. Do not use -W unless you also want transitive upgrades — it muddies the diagnosis if something breaks, because you no longer know whether the package or a dependency moved.

Unblocking the wider tree: composer why-not php 8.0 is the fastest way to see everything holding you back. This package is rarely the only one.

Implementation Patterns

Staged upgrade, one axis at a time. The classic trap is moving the runtime and the package in the same deploy. Do it in two: (a) bump to 4.1.0 while still on your current PHP version, run it in production for a cycle; (b) move the runtime to PHP 8. If something breaks you know which axis caused it. The reverse order works too — pick one and be consistent across services so the failure modes you've already debugged stay relevant.

Framework gate before package gate. Before you spend a day on this package, confirm your Laravel version runs on PHP 8 at all. In this window, that means checking laravel/framework in composer.lock against the framework's own release notes. Testing the package against an unsupported framework/PHP pairing produces noise you'll misattribute to the package.

CI matrix as the real verification. Add a job that runs your application's suite on PHP 7.4 and PHP 8.0 with v4.1.0 installed. Your suite exercises the integration points — container bindings, config values, model events — that a package's own tests mock away. Keep the 7.4 leg green: a compatibility release must not regress the runtime you're leaving.

Pin the runtime patch, not just the minor. PHP 8.0.0 was weeks old and patch releases landed monthly. Pin your containers/hosts to a specific 8.0.x you actually tested; "PHP 8" in a Docker tag will silently drift under you mid-rollout.

Version-gated syntax if your app spans runtimes. If the same codebase deploys to PHP 7.4 and 8.0 hosts during the transition, guard any PHP-8-only syntax so the 7.4 host doesn't parse-error at boot. This is the most common way a "compatibility release" takes down the older environment.

Wrap it behind your own boundary. If the package is currently called from controllers or Blade templates in more than a handful of places, use this upgrade as the excuse to funnel it through one service class or facade. Compatibility bumps are cheap when the surface is one class and expensive when it's thirty call sites.

Contract tests over snapshot tests. If the package produces output (rendered fragment, serialized payload, generated file), assert on semantic shape rather than byte-for-byte snapshots. PHP 8 changed string-to-number comparison and mixed-type sort ordering; byte-identical snapshots will churn for reasons that don't matter, and the noise will hide the one difference that does.

Gotchas and Tips

• The changelog is thinner than the diff. One line of notes for a minor version usually hides dependency bumps, minimum-version raises, and deprecation shims. Read the actual diff between the 4.0.x tag you're on and 4.1.0: composer.json, any *.php containing @deprecated, and the test suite's skipped tests are where the real story is.

• PHP 8.0 behaviour changes are the likeliest breakage, not the package's own code. In rough order of how often they bite: null passed to non-nullable internal function parameters now throws TypeError (common across string/array functions); string-to-number comparison semantics changed, so 0 == "foo" is now false; implode()'s reversed argument order was removed; create_function(), each(), money_format() and ereg* are gone entirely; calling non-static methods statically is now an Error, not a deprecation.

• Error reporting defaults changed. PHP 8 sets error_reporting to E_ALL by default, and @ no longer silences fatal errors. Code that was quietly swallowing notices on 7.4 will start talking on 8.0. That's useful, but budget for the log volume.

• Deprecations are not errors, so tests pass and logs fill. Run the suite with error_reporting(E_ALL) and fail the build on deprecations for one cycle. Silent deprecation debt is what turns the next upgrade into a mandatory fire drill instead of a routine bump.

• Expect a 4.1.1. A four-week-old runtime means edge cases surface in the wild, not in CI. Subscribe to the repo's issue tracker and watch for PHP-8-specific reports before rolling this across every service; the first service is your canary for the package's own bugs, not just yours.

• Composer's platform check vs. your actual runtime. config.platform.php in composer.json pins resolution to a version that may not match production. If you set it for a legacy deploy target and forgot, you'll resolve a dependency set that "supports PHP 8" on paper and fails at runtime. Verify with composer check-platform-reqs on the real host or in a matching container.

• Autoloader and opcache staleness after a constraint change. After bumping the package, run composer dump-autoload and clear opcache/compiled caches (including php artisan config:clear / view:clear if config is cached). Class-not-found errors immediately after a version bump are almost always this, not a genuine incompatibility.

• Lock files on multi-service repos. If several services share the package, upgrade them independently rather than in one lockstep PR. Batching removes your ability to isolate a regression, and with a brand-new runtime you should assume there will be one.

• Extension points to prefer. Whatever the package exposes — container bindings, config keys, events, a facade over an interface — bind your own implementation rather than subclassing its concrete classes. Subclassing is what makes minor bumps breaking in practice, because internal constructors and protected members are not covered by semver.

• If you cannot find a Laravel version matrix, assume nothing. "PHP 8 support" says nothing about framework compatibility. Test on your actual Laravel version before scheduling the rollout, and record in your own changelog what you verified and when — the next developer to bump this package will need it, and in this window the framework/PHP pairing is the thing most likely to have changed underneath them.