Coverage Check Laravel Package

Getting Started

This is a major release (2.0.0) and the only documented change is a raised floor: PHP 8.0+ is now required, plus some Symfony warning/issue cleanup. There is no new feature surface to learn, so the first job is confirming your runtime can accept it.

Start here, in order:

1. Check your PHP version and constraint.

   php -v
   composer why-not php 8.0
   

   If you are on 7.4, you cannot install ^2.0. Either upgrade the runtime first or stay pinned to the 1.x line (assuming it is still maintained — verify on the package's release page).

2. Read the package's composer.json for the new php and symfony/* constraints. This tells you what the transitive dependency floor looks like before you touch your lock file.

3. Check for an UPGRADING.md or CHANGELOG entry. The release notes are thin; a major bump usually implies at least the PHP constraint change, and sometimes removed deprecated methods that were not called out. Diff the public API against your usage.

4. First use case — a smoke test, not a feature build. After composer update, run an existing feature test that exercises the package, or drop into php artisan tinker and hit the primary entry point. The goal is to confirm the service provider boots and the container bindings resolve on PHP 8.

Implementation Patterns

• Upgrade in an isolated branch. Bump the constraint to ^2.0, run composer update vendor/package --with-dependencies, and let CI tell you what broke. Do not mix this with other dependency upgrades.
• Update your CI matrix explicitly. If you still test on 7.4, that job will now fail to install. Move the matrix to 8.0, 8.1, 8.2, 8.3 and treat 8.0 as the compatibility floor, not the target.
• Pin the major in composer.json ("vendor/package": "^2.0") rather than using *, and commit the lock file so deployments are reproducible.
• Verify Symfony warning fixes in your own logs. If your app routes deprecations to a log channel, compare deprecation output before and after the upgrade. Anything that disappears is the package's fix; anything that appears is your regression signal.
• Standard Laravel integration still applies: bind any package interfaces in a service provider, publish config with php artisan vendor:publish --provider=..., and run php artisan config:cache after deploying to confirm the package tolerates cached config.
• If you use the package in queued jobs, re-run a worker smoke test — Symfony-level fixes occasionally touch serialization or console output, and a long-running worker can mask that until it restarts.

Gotchas and Tips

• This is a breaking change by definition, even though the diff sounds small. composer update on a PHP 7.4 host will fail with an unsatisfiable constraint. Plan the runtime upgrade and the package upgrade as one piece of work.
• Watch transitive constraints. Dropping PHP < 8.0 in this package often means it now requires newer symfony/* components. Use composer update vendor/package --with-dependencies and review the full composer.lock diff, not just the one package.
• PHP 8.0 itself is end-of-life. The package now supports 8.0 as a minimum, but you should be running 8.2 or 8.3 in production. Treat 8.0 support as a compatibility statement, not a recommendation.
• "Fixes Symfony warnings" can mean behavior changed. A silenced deprecation sometimes becomes a different code path. Skim the upstream diff if the package is security- or data-sensitive, and run your full test suite rather than relying on the release note.
• Debugging an install failure: composer diagnose, then composer why-not vendor/package 2.0.0 to see exactly which constraint blocks you. php artisan about confirms the runtime Laravel sees after a deploy.
• Extension points to re-check after a major bump: published config files (re-publish and diff, since defaults may have moved), facade accessors, and any class you have extended. Major versions are the most likely time for protected methods to be renamed.
• If you cannot upgrade yet, pin "vendor/package": "^1.0" explicitly and add a note to your upgrade backlog with the PHP floor as the blocker. Do not leave it unconstrained, or a future composer update will attempt the jump for you.