Każdy to zna. Jest spokojny poniedziałek, kawa jeszcze ciepła, projekt jakoś się trzyma na taśmie klejącej i nadziei, a tu nagle ktoś mówi:
„Może byśmy zrobili upgrade PHP do wersji 8?”.
I w tym momencie gdzieś w serwerowni gaśnie światło, a sysadmin czuje niepokój w odbycie. Bo to nie jest pytanie. To jest zapowiedź katastrofy.
Bo przecież „to tylko upgrade”
Upgrade. Jak update Windowsa. Klik, klik, restart i jazda. Co może pójść nie tak?
Otóż wszystko.
PHP 7.4 działa. Nie idealnie, nie pięknie, ale działa. A PHP 8? PHP 8 to jest ten kolega, który przychodzi na imprezę, przestawia meble i mówi, że „teraz jest bardziej nowocześnie”, po czym wychodzi, a ty zostajesz z rozwalonym salonem i niekompatybilnym ORM-em.
Breaking changes, czyli „mieliśmy standardy, ale je wyjebaliśmy”
PHP 8 wprowadza breaking changes. Oficjalnie: “improvements”. W praktyce:
– coś, co w 7.4 było warningiem, teraz jest fatal errorem
– coś, co wcześniej zwracało null, teraz wywala wyjątek
– coś, co działało przez 10 lat, teraz „nie jest zgodne z filozofią języka”
A ty siedzisz i patrzysz w stack trace, który wygląda jak wiersz wolny napisany przez debila po trzech piwach.
Kod, który był brzydki, ale stabilny, nagle przestaje działać, bo PHP 8 postanowiło mieć zdanie. A nikt go o to nie prosił.
Biblioteki, które „już prawie wspierają PHP 8”
Najlepsza część? Zależności.
Masz projekt oparty na 27 bibliotekach, z czego:
-
5 jest porzuconych od 2016,
-
10 „planuje wsparcie PHP 8 w przyszłości” (czyli nigdy),
-
3 działają, ale tylko jak wyłączysz połowę funkcji,
-
2 mają pull requesta z fixem, ale maintainer „jest zajęty życiem”.
Composer zaczyna przypominać grę w rosyjską ruletkę, tylko zamiast naboju masz konflikt wersji, a zamiast nagrody — deploy rollback o 2 w noc
Dodaj komentarz