TLDR;

Rector - The Power of Automated Refactoring is now 100% completed

Tomas Votruba and I first met a couple of years ago at one of my favorite conferences; the Dutch PHP Conference in Amsterdam (so actually, we're very close to our anniversary, Tomas!). He presented Rector there and it was really inspiring. A year later I was working on a legacy migration problem: our team wanted to migrate from Doctrine ORM to "ORM-less", with handwritten mapping code, etc. I first tried Laminas Code, a code generation tool, but it lacked many features, and also the precision that I needed. Suddenly I recalled Rector, and decided to give it a try. After some experimenting, everything worked and I learned that this tool really is amazingly powerful!

Thank you, Tomas

I asked Tomas if he would like to write a book together, about Rector, combining the perspective of a developer who needs to learn how to use and extend Rector, with the perspective of the creator who has a vision for the project. This turned out to be a very fruitful collaboration. To be extremely honest, in the beginning of the project I was really annoyed by Tomas' contributions. As an example, this guy put all of the value object classes in a namespace called ValueObjects. I had never encountered anything like that. He also added all kinds of PHPStan rules that would throw errors in my face whenever I tried to commit anything. At first I was like: that is not how writing a book works, Tomas. You're treating it as a software project. I want to have freedom. I want to treat it like art.

In the end, I realized we were optimizing for different things. He focused on:

• Achieving the simplest possible setup for service container configuration.
• Never having to remember any special rule: a failing build should remind you of your mistakes.
• Maximum maintainability in the long run. This book needs to be useful not only this year, but during the life span of the project itself.

These are very valuable principles, and from this place I'd like to thank Tomas for leading by example here. I'll never forget this, and will make it part of every future project (books and software projects alike). Thanks to this approach, every code sample is analyzed for issues, automatically formatted, and every code sample can be automatically refactored with Rector. When we need to, we can even upgrade the code base to a new PHP version. In fact, we could even decide to downgrade it!

Rector is better because of this book

While writing I often encountered a weird problem. Sometimes it turned out to be bug in Rector, sometimes an edge case that would be solved by a feature that was already on the roadmap (like migrating Rector to use static reflection). In all cases, Tomas was able to improve Rector, making the learning experience for news users much smoother, and more enjoyable.

You'll be a better developer because of this book

Rector is a fascinating tool, but before you can effectively extend it for your own code transformation needs, you have to learn about some other related topics, like tokenizing, parsing, the Abstract Syntax Tree, node visitors, and so on. This book aims to provide a good introduction to all these topics, making you a better developer anyway, even if you'd never actually use Rector.

Conclusion

In conclusion: buy this book. It's now 100% complete. It'll teach you a lot about PHP as a language, how to improve legacy projects without wasting development time, and even about test-driven development.