Do you want to migrate your project from Nette to Symfony? In the part 2 we looked at escaping semver hell.
Today we'll look on package vendor-locks caused by brain drain.
This post will be a bit harder for me because I'm part of this problem. I'm a former Nette activist and open-source hyper. I created many open-source packages Nette developers use, but those are not actively maintained nor developed for the last couple of years. I'm sorry about that.
If you love Nette, keep using it. This post is for people, whose companies are hurt by being locked to Nette ecosystem and who want to solve that but don't know how or if that is even possible.
When we talked with Honza about framework A → framework B migration first related to Entry.do, it was on the first PHP Mountains 2017. Rector was still 5 months before being born, so manual work was the only way.
First, we looked into
composer.json and tried to get rid of some packages. What packages we won't need on Symfony?
We could drop all these, because:
kdyby/* is basically integration of Symfony packages with
zenify/* is basically
doctrine/* integration with
Of course, you can't delete them right away. Yet, Rector covers most of this migration now, so this part is fine.
We decided to remove Symfony/Doctrine glue packages first, so we could work with fewer dependencies and be more flexible. And upgrade PHP first, so we can use right the newest Symfony packages.
We tried to remove one
zenify/* package (because it's small → possibly easy to replace) and use the package we have in control.
Thing is, PHP 7.2 introduced
Nette had class
Nette\Object that was actively promoted as the parent of all classes in your code. Now it had *to be removed from all these classes and replaced by trait:
-class SomeClass extends Nette\Object
+ use Nette\SmartObject;
If you still have this problem, use Rector that handles this case.
In that time, we had to use PHPStorm old-school find & replace with regex pattern:
The upgrade path is like a road with holes. It's getting crappy, but there is still at least some road 👍
But what if there are many packages, that nobody actively takes care of?
Until the maintainer fixes that, the upgrade path is closed. We'd have to fork every Nette package that is not maintained, fix it manually in the code and add them into
We don't talk about small package with few classes that is easy to rewrite:
Most of Kdyby packages still have 500-900 daily downloads. Even if we take CI servers into account, that still might be 120-150 PHP applications locked to legacy with packages that no-one maintains.
"When you stop growing, you start dying."
With a healthy active community as in Laravel or Symfony, there would be PR and we never came across this problem. What's different with Nette?
David Grudl, the author of Nette tweeted at the end of 2013 that he ends with Nette. "One tweet", you might think, but there was more of similar news on Nette forum and popular Czech IT blogs.
Many years later, when I become a Symfony consultant, I asked companies why did they choose Symfony over Nette. After all, there were Nette meetups in our the Czech Republic every month and maybe 2 non-Nette PHP meetups about other frameworks. The answer was almost unanimous: when they discussed what PHP framework to use, they saw David's tweet. They needed something stable they could for the next 5 years.
Many of open-source packages for Nette slowly become unmaintained. So this error is new status-quo for these packages:
When we realized with Honza that night, that to upgrade project means "fork every unmaintained dependency and I hope there will be better times", we stopped. But the motivation remained and 2 years later, with better skills and Rector, we managed to migrate the application from Nette to Symfony in less than a month.
Are you stuck with Nette at home and thinking about in your wet dreams Symfony? This is your lucky week! :)
Honza Mikes will talk about Nette to Symfony migration on PHP meetup in Prague this Thursday - 14. 3.
Entrance free, language is English and I'll be there too!
Do you learn from my contents or use open-souce packages like Rector every day?
Consider supporting it on GitHub Sponsors. I'd really appreciate it!