If you've been putting off moving your project to PHP 8.2, you're not alone — version bumps feel risky, and nobody wants to break a working codebase. The good news is there's a tool that handles the boring parts for you, and according to amitmerchant.com, it takes care of most of the heavy lifting through a single command.
We took a closer look at the walkthrough and pulled out what matters for developers who want to modernize their stack without spending a weekend untangling deprecation warnings.
The short version:
- The post walks through modernizing a PHP codebase for PHP 8.2 using the Rector tool
- PHP 8.2 is described as an incremental upgrade layered on PHP 8 and PHP 8.1, with a recommended upgrade order of 8 → 8.1 → 8.2
- Rector is added as a development dependency in the project
- The tool relies on configurable "rules" to apply the PHP 8.2 transformations
- Sample rules shown include ReadOnlyClassRector and Utf8DecodeEncodeToMbConvertEncodingRector
- A –dry-run flag lets developers preview the changes as a diff before anything is written
- Removing –dry-run and re-running applies every change for real
How the Rector Upgrade Process Works
Rector is not magic. It's a static analysis tool that rewrites your code based on a set of rules you define inside a configuration file. For PHP 8.2, that configuration registers the specific rule classes which know how to swap older patterns for newer ones. The walkthrough demonstrates this with two examples: ReadOnlyClassRector, which handles the readonly class changes introduced in 8.2, and Utf8DecodeEncodeToMbConvertEncodingRector, which rewrites utf8_decode and utf8_encode calls to their mb_convert_encoding equivalents.
Once your configuration is in place, the workflow is genuinely simple. Point Rector at a folder — in the example, src — and let it scan your code. With –dry-run, it shows every change it would make as a diff, without touching a single file. Read through them, sanity-check anything that looks suspicious, then re-run without the flag to apply everything for real.
Who Should Care About This
If you maintain any PHP project that's more than a year old, this is for you. Manual refactoring for a major version bump is how bugs are born. You skim a deprecation warning, miss another, and six months later something breaks in production. Rector's strength isn't that it's clever — it's that it's exhaustive and repeatable. You can run it across dozens of repositories and get the same transformations every time.
The author also makes a point of framing PHP 8.2 as a step on top of what came before. That sequence matters. Trying to jump straight from PHP 7.4 to 8.2 in one shot is how you end up with rule conflicts and confusing diffs. Going 7.4 → 8.0 → 8.1 → 8.2 lets you isolate which rule sets apply at each stage.
A Practical Example
Say you maintain a small Laravel app that's been on PHP 8.0 since launch. You've been meaning to move to 8.2 for the readonly class support and better error messages. Here's how the Rector approach plays out in practice:
- Install Rector as a dev dependency: composer require –dev rector/rector
- Create a rector.php config file in your project root
- Register the PHP 8.2 rule classes you want active
- Run vendor/bin/rector process app –dry-run and review the diff
- If everything looks clean, run vendor/bin/rector process app to apply
Total time for a small codebase: under thirty minutes, plus however long you spend reviewing the diff.
What to Watch Next
If you're already on PHP 8.0 or 8.1, there's no reason to keep postponing the 8.2 bump — Rector makes the mechanical part trivial, and the only real work is reviewing what it would change. If you're still on PHP 7.x, do the sequential upgrades first; the rule sets are designed to stack cleanly.
One thing to keep in mind: Rector handles the automatic transformations. Anything semantic — like deciding whether your code actually benefits from readonly classes — is still on you. Treat the dry-run output as a starting point, not a finish line.
Key takeaways
- Upgrade in sequence (8.0 → 8.1 → 8.2) rather than jumping versions
- Always run –dry-run first to review proposed changes before applying
- Configure only the rule classes relevant to your target PHP version
- Rector handles mechanical refactoring, not architectural decisions
Frequently asked questions
Do I need to upgrade to PHP 8.0 and 8.1 before going to 8.2?
Yes. The author specifically recommends upgrading in sequence, since PHP 8.2 is described as incremental on top of earlier versions, and the rule sets are designed to stack.
What does the –dry-run flag do in Rector?
It shows you every change Rector would make as a diff, without modifying any files. Use it to review before committing to the real run.
Is Rector safe to run on a production codebase?
The tool itself is safe — it only writes files when you drop –dry-run. The real risk is in the transformations themselves, which is exactly why the dry-run review step exists.
Can Rector handle every PHP 8.2 change automatically?
No. It handles the mechanical, rule-based transformations. Semantic changes — like adopting readonly classes where they actually make sense — still require human judgment.