reiterus/app-stats-symfony
Symfony bundle that integrates app-stats to collect, track, and display application usage metrics. Provides service configuration and Symfony-friendly hooks for monitoring key statistics within your app.
Treat v2.0.0 as a platform floor change first and a feature release second. The only documented change is the PHP 8.1 minimum, so your first job is proving your runtime and dependency graph actually satisfy it.
composer why-not php 8.1 and composer why-not <vendor>/<package> 2.0 will tell you exactly which package is holding you at 8.0 before you touch anything.composer.json to "php": "^8.1", then composer update <vendor>/<package> --with-dependencies. Commit the lock file separately from any code changes so the upgrade is bisectable.php:8.1-cli/php:8.1-fpm), CI matrix entries, platform.php in config.platform, and any phpstan/phpcs/pint configs that pin a phpVersion.php artisan about, then the full test suite. If you have no tests, at minimum exercise the package's main entry point (its facade, service provider binding, or console command) through php artisan tinker.CHANGELOG.md and any UPGRADING.md, then its composer.json for the illuminate/* and symfony/* constraints — that tells you which Laravel versions v2 actually pairs with, which the release note does not.Your first real use case is almost always the same: you have a scheduled job, queue worker, or HTTP path that depends on this package, and you want that path green on 8.1 before you widen the blast radius.
Pair the PHP floor with a Laravel floor. A package that requires PHP 8.1 in a major release usually also drops older illuminate/* majors. Resolve the Laravel constraint and the PHP constraint together in one PR; splitting them creates a matrix of untested combinations.
Stage the rollout in three steps. (a) Bump PHP to 8.1 on the old package version and confirm your app is stable — this isolates runtime changes from API changes. (b) Upgrade the package to ^2.0 with no other changes. (c) Only then adopt any 8.1 language features in your own code. If step (a) fails, the failure is yours; if step (b) fails, it's the package's, and you know who to file the issue with.
Update the CI matrix deliberately. Rather than replacing 8.0 with 8.1, run both for one release cycle if your application code still claims ^8.0. Once the package is at v2, drop the 8.0 entry in the same commit that raises your own composer.json floor, so the manifest and the matrix never disagree.
Modernise opportunistically, not as a prerequisite. PHP 8.1 gives you backed enums, readonly properties, first-class callable syntax, never return types, and new in initializers. If the package exposes status/type values, prefer enums over class constants at call sites. If it returns DTOs, wrap or extend them with readonly properties to make immutability explicit. Use Rector with the PHP_81 set on a separate branch to keep these mechanical changes out of the upgrade diff. First-class callable syntax ($this->handle(...)) is a low-risk win for anything you pass to array_map, Collection::map, or queue callbacks.
Pin the platform for reproducibility. Set "config": { "platform": { "php": "8.1.0" } } in applications (not libraries) so local and CI resolution agree, and so a developer on 8.3 doesn't resolve a dependency tree your production 8.1 box cannot install.
Keep a rollback plan. A major bump is semver-breaking by definition. Note the exact 1.x constraint ("<vendor>/<package>": "^1.4") in the PR description; if v2 regresses in production, composer require back to it is a one-liner plus a lock-file revert.
--ignore-platform-reqs is a trap here. It will happily install v2 on PHP 8.0 and then fail at runtime with a parse error on typed constants or readonly syntax. If you're tempted to use it, you need a different PHP binary, not a flag.null to non-nullable internal function parameters (e.g. strlen(null), htmlspecialchars(null)), implicit incompatible float-to-int conversion, and ArrayAccess/Iterator/Countable implementations missing return types. The last one is fixed by adding #[\ReturnTypeWillChange] or a real return type — if the package implements any of these interfaces, check whether v2 added them; if it didn't, you'll get deprecation spam in logs.$GLOBALS write/read restrictions landed in 8.1. Legacy config or testing helpers that mutate globals will break; audit any phpunit.xml bootstrap or test helper that does this.json_encode(SomeEnum::Case) fails for pure enums, and backed enums serialize to their scalar only via ->value. If the package returns enums and you pass those values straight into an API resource or a cache payload, convert at the boundary.->fill(), and hydration patterns that mutate after construction will throw — you'll need constructor injection or new in initializers.php:8.1 images ship slightly different default extensions than 8.0 images. Rebuild from a clean image rather than pulling; then verify intl, bcmath, gd, and pdo_* are all still present.git diff 1.x..2.0.0 -- src/ against the package's config file, service provider bindings, published migrations, and facade docblocks. Majors are when maintainers sneak in renames.composer.json for provide/replace and autoload changes. A PSR-4 root namespace shift in a major will break any class you've extended or aliased in config/app.php, and it fails loudly only at the point of use.singleton vs scoped (relevant under Octane — a singleton that holds request state will leak across requests), and whether any interfaces gained methods. Adding a method to an interface is a breaking change that the PHP-version note won't mention; if you implement any of the package's contracts, diff them by hand.How can I help you explore Laravel packages today?