agentsclimarketplace

Php upgrade

Skill krzysztofsurdy/code-virtuoso/skills/playbooks/php-upgrade

Skills, sub-agents, and playbooks for Claude Code, Cursor, and any Agent Skills-compatible AI coding assistant.

Install
npx -y skills add krzysztofsurdy/code-virtuoso --skill php-upgrade

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Step-by-step PHP version upgrade playbook for PHP 8.0 through 8.4+ with automated tooling. Use when the user asks to upgrade PHP to a new version, check PHP compatibility, fix deprecation warnings, run Rector for automated refactoring, audit code with PHPCompatibility, or plan a PHP migration strategy. Covers breaking changes per version, php.ini configuration updates, extension compatibility, Rector rule sets, testing strategies, and the changelog-first upgrade workflow.

SKILL.md

7.9 KB, as published. Nobody here has run it

PHP Version Upgrade

Upgrade one minor version at a time. Never skip versions - each step surfaces deprecations that become errors in the next release. Every upgrade follows the same cycle: audit, automate, test, deploy.

Core Principles

PrincipleMeaning
Changelog firstBefore any upgrade, search the web for the official PHP migration guide (php.net/migration) or ask the user for the changelog - never rely on static knowledge alone
One version at a timeUpgrade 8.1 -> 8.2 -> 8.3 -> 8.4 sequentially - skipping versions makes it impossible to isolate breakage
Fix deprecations before upgradingDeprecations in version N become errors in version N+1 - treat them as mandatory fixes
Automate first, manual secondRun Rector and PHPCompatibility before touching code by hand - they catch 80%+ of required changes
Prove it with testsNever consider an upgrade complete without a passing test suite on the target version
Pin your platformSet config.platform.php in composer.json to match your lowest deployment target

Upgrade Process Overview

Phase 0: Read the Changelog

Before touching any code, obtain the actual changelog for the target PHP version:

  1. Search the web for PHP X.Y migration guide (e.g., PHP 8.4 migration guide php.net)
  2. Or ask the user to provide the changelog / release notes
  3. Read the official migration page at https://www.php.net/manual/en/migrationXY.php

This is non-negotiable. Each version has unique changes that static skill knowledge cannot fully capture.

Phase 1: Audit

Before changing any code, understand the scope of the upgrade.

  1. Run PHPCompatibility against the target version to identify incompatible code
  2. Run php-parallel-lint with the target PHP binary to catch syntax errors
  3. Run composer outdated to check if all dependencies support the target version
  4. Review the official migration guide at php.net for the target version
  5. Check PHP extensions for compatibility (ext-intl, ext-mbstring, etc.)

Phase 2: Automate

Use Rector to handle the bulk of code transformations automatically.

// rector.php
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withPhpSets(php84: true);  // adjust to target version

Always dry-run first:

vendor/bin/rector process --dry-run

Review changes, then apply:

vendor/bin/rector process

Commit Rector changes separately from manual fixes for clean git history.

Phase 3: Update Dependencies

  1. Update composer.json with the new PHP version constraint: "php": ">=8.4"
  2. Update config.platform.php to match the target version
  3. Run composer update and resolve conflicts
  4. Update PHP extensions as needed

Phase 4: Test and Deploy

  1. Run the full test suite under the new PHP version
  2. Run static analysis (PHPStan/Psalm)
  3. Deploy to staging and verify
  4. Monitor production logs for deprecation notices after deployment

See Upgrade Process Reference for detailed tool configuration, CI pipeline setup, and Docker considerations.


Tools

ToolPurposeWhen to Use
RectorAutomated AST-based code transformationFirst step after auditing - handles most mechanical changes
PHPCompatibilityPHP_CodeSniffer ruleset for cross-version compatibilityAudit phase - identifies all incompatible code before you start
php-parallel-lintParallel syntax checking (~20x faster than serial)Audit phase - catches syntax errors under the new version
PHPStan/PsalmStatic analysisVerification phase - catches type errors after transformation
symfony/phpunit-bridgeDeprecation summary in test outputOngoing - monitors deprecation count during upgrades

Breaking Changes by Version

TransitionKey Breaking Changes
8.0 -> 8.1Fibers introduced, enums added, readonly properties, intersection types, never return type
8.1 -> 8.2Dynamic properties deprecated (use #[AllowDynamicProperties] temporarily), $GLOBALS access restrictions, readonly classes, disjunctive normal form types
8.2 -> 8.3Typed class constants, json_validate() added, #[Override] attribute, Randomizer additions, date/time exception changes
8.3 -> 8.4Implicit nullable types deprecated (function foo(string $bar = null) must become ?string $bar = null), property hooks, asymmetric visibility, new without parentheses deprecated for no-arg constructors, DOM extension namespace changes

See Version Changes Reference for complete per-version details with code examples.


Common Pitfalls

PitfallWhy It HurtsPrevention
Skipping versionsCannot isolate which changes broke whatAlways upgrade one version at a time
Ignoring deprecation warningsDeprecations become fatal errors in the next versionFix all deprecations before upgrading
Not checking dependenciesThird-party packages may not support the target versionRun composer outdated and check support before starting
Using --ignore-platform-reqsBypasses safety checks, causes runtime errorsNever use it - fix the actual constraints instead
Not pinning config.platform.phpLocal PHP differs from production, causing install mismatchesAlways set it to match production
Large unreviewed Rector runsRector can make incorrect transformations in edge casesAlways dry-run first, review changes, run on small batches
Forgetting PHP extensionsExtensions change behavior or get deprecated between versionsAudit all required extensions before upgrading

Quick Reference: Upgrade Checklist

  • Review php.net migration guide for target version
  • Run PHPCompatibility scan against target version
  • Run php-parallel-lint with target PHP binary
  • Verify all Composer dependencies support target version
  • Configure and run Rector with target version set (dry-run first)
  • Review and commit Rector changes
  • Apply manual fixes for remaining issues
  • Update composer.json PHP constraint and config.platform.php
  • Run composer update
  • Run full test suite on target PHP version
  • Run static analysis (PHPStan/Psalm)
  • Deploy to staging and verify
  • Deploy to production and monitor logs

Reference Files

ReferenceContents
Upgrade ProcessDetailed tool configuration, CI pipeline setup, Docker strategy, and step-by-step commands
Version ChangesPer-version breaking changes, new features, and deprecations with code examples (PHP 8.0 through 8.4)

Integration with Other Skills

SituationRecommended Skill
Upgrading Symfony alongside PHPUse the symfony-upgrade skill in frameworks/symfony/
Updating Composer dependencies after PHP upgradeUse the composer-dependencies playbook skill
Modernizing PHP code patterns (DTOs, enums, strict types)Install php-modernization from dirnbauer/webconsulting-skills or netresearch/php-modernization-skill
Running static analysis after upgradeInstall knowledge-virtuoso from krzysztofsurdy/code-virtuoso for testing strategies

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.