{"id":40183,"date":"2021-10-06T14:18:40","date_gmt":"2021-10-06T12:18:40","guid":{"rendered":"https:\/\/kinsta.com\/?p=100177"},"modified":"2023-06-07T09:01:48","modified_gmt":"2023-06-07T07:01:48","slug":"transpilen-php","status":"publish","type":"post","link":"https:\/\/kinsta.com\/nl\/blog\/transpilen-php\/","title":{"rendered":"De ultieme handleiding voor het transpilen van PHP code"},"content":{"rendered":"

In ideale omstandigheden zouden we voor al onze sites PHP 8.0<\/a> (de laatste versie op het moment van schrijven) gebruiken en deze updaten zodra er een nieuwe versie uitkomt. In de praktijk werken developers echter vaak uit noodzaak met oudere PHP versies, zoals wanneer je een openbare plugin voor WordPress<\/a> maakt of werkt met verouderde code die het upgraden van de webserveromgeving belemmert.<\/p>\n

In deze situaties kunnen we al snel de hoop opgeven om de meest recente PHP versie te gebruiken. Maar er is een beter alternatief: we kunnen onze broncode schrijven met PHP 8.0 en deze transpilen naar een eerdere PHP versie – zelfs naar PHP 7.1.<\/p>\n

In deze gids leren we je alles wat je moet weten over het transpilen van PHP code.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Wat is transpilen?<\/h2>\n

Door te transpilen converteer je de broncode van een programmeertaal<\/a> naar equivalente broncode van dezelfde of een andere programmeertaal.<\/p>\n

Transpilen is zeker geen nieuw concept binnen webontwikkeling: client-side developers zijn waarschijnlijk wel bekend met Babel<\/a>, een transpiler voor JavaScript code.<\/p>\n

Babel converteert JavaScript code van de moderne ECMAScript 2015+ versie naar een oudere versie die compatibel is met oudere browsers. Als de tool een ES2015 arrow functie krijgt:<\/p>\n

[2, 4, 6].map((n) => n * 2);\n<\/code><\/pre>\n
… dan converteert Babel het naar een ES5 versie:<\/p>\n
[2, 4, 6].map(function(n) {\n  return n * 2;\n});\n<\/code><\/pre>\n
Wat is het transpilen van PHP?<\/h3>\n
Wat potentieel nieuw is binnen webontwikkeling: de mogelijkheid om server-side code te transpilen, en dan in het bijzonder PHP.<\/p>\n
Het transpilen van PHP werkt op dezelfde manier als het transpilen van JavaScript: broncode van een moderne PHP versie<\/a> wordt geconverteerd naar een equivalente code voor een oudere PHP versie.<\/p>\n
In de lijn van hetzelfde voorbeeld als hierboven, een arrow functie van PHP 7.4:<\/p>\n
$nums = array_map(fn($n) => $n * 2, [2, 4, 6]);\n<\/code><\/pre>\n
… kan worden getranspileerd naar de equivalente PHP 7.3 versie:<\/p>\n
$nums = array_map(\n  function ($n) {\n    return $n * 2;\n  },\n  [2, 4, 6]\n);\n<\/code><\/pre>\n
Arrow functies kunnen worden getranspileerd omdat ze syntactic sugar<\/a> zijn, dat wil zeggen een nieuwe syntax om een bestaand gedrag te produceren. Dit is het laaghangende fruit.<\/p>\n
Maar er zijn natuurlijk ook nieuwe features die nieuw gedrag cre\u00ebren, waarvoor dus geen equivalente code bestaat in eerdere versies van PHP. Dat is het geval met union types<\/a>, die werden ge\u00efntroduceerd in PHP 8.0:<\/p>\n
function someFunction(float|int $param): string|float|int|null\n{\n  \/\/ ...\n}\n<\/code><\/pre>\n
In deze situaties is transpilen nog steeds mogelijk, zolang de nieuwe feature nodig is voor ontwikkeling, maar niet voor productie. We kunnen in dat geval de feature helemaal uit de getranspileerde code verwijderen zonder ernstige gevolgen.<\/p>\n
Een voorbeeld hiervan zijn union types. Deze feature wordt gebruikt om te controleren of er geen mismatch is tussen het input type en de opgegeven waarde, wat bugs helpt voorkomen. Als er een conflict is met types, dan zie je fout al in de ontwikkelingsfase. Dit betekent dat we, voordat de code de productie-omgeving bereikt, de fout kunnen vinden en oplossen.<\/p>\n
Dat is dan ook de reden dat we het ons kunnen veroorloven om de feature uit de “productiecode” kunnen verwijderen:<\/p>\n
function someFunction($param)\n{\n  \/\/ ...\n}\n<\/code><\/pre>\n
Als de fout nog steeds optreedt in productie, dan zal de gegenereerde foutmelding minder nauwkeurig zijn dan wanneer we union types hadden. Dit potenti\u00eble nadeel wordt echter gecompenseerd door het feit dat we \u00fcberhaupt union types kunnen gebruiken.<\/p>\n\n
Voordelen van het transpilen van PHP code<\/h2>\n
Transpiling stelt iemand in staat om een applicatie te coderen met de nieuwste versie van PHP en een release te produceren die ook werkt in omgevingen met oudere versies van PHP.<\/p>\n
Dit kan met name handig zijn voor ontwikkelaars die producten maken voor oudere Content Management Systems (CMS)<\/a>. WordPress ondersteunt officieel nog steeds PHP 5.6<\/a> (hoewel het PHP 7.4+ aanbeveelt). Het percentage van WordPress sites met daarop PHP versies 5.6 tot 7.2 – die allemaal End-Of-Life (EOL) zijn, wat betekent dat ze geen beveiligingsupdates meer ontvangen – staat op een aanzienlijke 34,8%. Sterker nog, maar liefst 99,5% van de sites draait op een versie van eerder dan PHP 8.0:<\/p>\n
\"WordPress<\/a>
WordPress gebruiksstatistieken per versie. Bron: WordPress<\/a><\/figcaption><\/figure>\n
Als gevolg daarvan zijn WordPress thema’s en plugins die openbaar te verkrijgen zijn en een wereldwijd publiek bedienen, waarschijnlijk gecodeerd met een oudere versie van PHP om hun bereik te vergroten. Dankzij transpiling kunnen deze worden gecodeerd met PHP 8.0, en toch worden uitgebracht voor een oudere PHP versie, waardoor zoveel mogelijk gebruikers worden getarget.<\/p>\n
Elke toepassing die een andere PHP versie dan de meest recente moet ondersteunen (zelfs binnen het bereik van de momenteel ondersteunde PHP versies) kan dus profiteren.<\/p>\n
Dit is het geval met Drupal, waarvoor PHP versie 7.3 vereist is<\/a>. Dankzij transpiling kunnen developers openbaar beschikbare Drupal modules maken met PHP 8.0 en deze releasen met PHP 7.3.<\/p>\n
Een ander voorbeeld is het maken van aangepaste code voor klanten die om de een of andere reden geen PHP 8.0 in hun omgeving kunnen draaien. Desalniettemin kunnen ontwikkelaars dankzij transpiling hun deliverables nog steeds coderen met PHP 8.0 en ze in die oudere omgevingen uitvoeren.<\/p>\n
Wanneer PHP transpilen?<\/h3>\n
PHP code kan altijd worden getranspileerd, tenzij het een PHP feature bevat die geen equivalent heeft in de vorige PHP versie.<\/p>\n
Dat is mogelijk het geval met attributes<\/a> die werden ge\u00efntroduceerd in PHP 8.0:<\/p>\n
#[SomeAttr]\nfunction someFunc() {}\n\n#[AnotherAttr]\nclass SomeClass {}\n<\/code><\/pre>\n
In het eerdere voorbeeld met daarin arrow functies, kon de code worden getranspileerd omdat arrow functies syntactic sugar zijn. Attributes daarentegen cre\u00ebren geheel nieuw gedrag. Dit gedrag zou kunnen worden gereproduceerd binnen PHP 7.4 en lager, maar alleen door het handmatig te coderen, dus niet op basis van een tool of proces (AI zou een oplossing kunnen bieden, maar we zijn nog niet zover).<\/p>\n
Attributes die bedoeld zijn voor gebruik tijdens de ontwikkelingsfase, zoals #[Deprecated]<\/a><\/code>, kunnen op dezelfde manier worden verwijderd als union types. Maar attributes die het gedrag van de toepassing in productie wijzigen, kunnen niet worden verwijderd, en kunnen ook niet rechtstreeks worden getranspileerd.<\/p>\n
Vandaag de dag is er nog geen transpiler die code met PHP 8.0 attributes kan pakken om automatisch de equivalente PHP 7.4 code te produceren. Als je PHP code dus attributes moet gebruiken, wordt het transpilen erg lastig, zo niet onmogelijk.<\/p>\n
PHP features die kunnen worden getranspileerd<\/h3>\n
Dit zijn de features van PHP 7.1 en hoger die kunnen worden getranspileerd. Als je code alleen deze features gebruikt, dan kan je er zeker van zijn dat de getranspileerde applicatie zal werken. In alle andere gevallen moet je zelf kijken of de getranspileerde code geen foutmeldingen geeft.<\/p>\n\n\n\n\n\n\n\n\n\n
PHP Versie<\/th>\nFeatures<\/th>\n<\/tr>\n<\/thead>\n
7.1<\/td>\nEverything<\/td>\n<\/tr>\n
7.2<\/td>\n– object<\/code> type<\/a>
\n– parameter type widening<\/a>
\n– PREG_UNMATCHED_AS_NULL<\/code> flag in preg_match<\/code><\/a><\/td>\n<\/tr>\n
7.3<\/td>\n– Reference assignments in list()<\/code> \/ array destructuring<\/a> (behalve binnen foreach<\/code> \u2014 #4376<\/a>)<\/em>
\n– Flexible Heredoc en Nowdoc syntax<\/a>
\n– Trailing commas in functions calls<\/a>
\n– set(raw)cookie<\/code> accepteert $option argument<\/a><\/td>\n<\/tr>\n
7.4<\/td>\n– Typed properties<\/a>
\n– Arrow functies<\/a>
\n– Null coalescing assignment operator<\/a>
\n– Unpacking binnen arrays<\/a>
\n– Numeric literal separator<\/a>
\n– strip_tags()<\/code> met array van tag names<\/a>
\n– covariant return types en contravariant param types<\/a><\/td>\n<\/tr>\n
8.0<\/td>\n– Union types<\/a>
\n– mixed<\/code> pseudo type<\/a>
\n– static<\/code> return type<\/a>
\n– ::class<\/code> magic constant bijj objects<\/a>
\n– match<\/code> expressions<\/a>
\n– catch<\/code> exceptions allen per type<\/a>
\n– Null-safe operator<\/a>
\n– Class constructor property promotion<\/a>
\n– Trailing commas in parameter lists en closure use<\/code> lists<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
PHP transpilers<\/h2>\n
Momenteel is er \u00e9\u00e9n tool voor het transpilen van PHP code: Rector<\/a>.<\/p>\n
Rector is een PHP reconstructortool, die PHP code converteert op basis van programmeerbare regels. We voeren de broncode in en de reeks regels<\/a> die moeten worden uitgevoerd, en Rector zal de code transformeren.<\/p>\n
Rector wordt bediend via de opdrachtregel en wordt via Composer in het project ge\u00efnstalleerd. Bij uitvoering zal Rector een “diff” (toevoegingen in groen, verwijderingen in rood) van de code geven (van voor en na de conversie):<\/p>\n
\"\"diff\"<\/a>
“diff” output van Rector<\/figcaption><\/figure>\n
Naar welke PHP versie je moet transpilen<\/h2>\n
Om code naar andere PHP versies te transpilen, moeten de bijbehorende regels worden gemaakt.<\/p>\n
Tegenwoordig bevat de Rector bibliotheek de meeste regels die je nodig hebt voor het transpilen van code binnen het bereik van PHP 8.0 tot 7.1. We kunnen dus met redelijk vertrouwen PHP code transpilen tot versie\u00a0 7.1.<\/p>\n
Ook zijn er regels voor het transpilen van PHP 7.1 tot 7.1<\/a> en van 7.0 tot 5.6<\/a>, maar deze regels zijn niet uitputtend. Er wordt aan gewerkt om ze te voltooien, zodat we PHP code uiteindelijk naar versie 5.6 kunnen transpilen.<\/p>\n
Transpilen vs backporten<\/h2>\n
Backporting is vergelijkbaar met transpilen, maar simpeler. Het backporten van code is niet noodzakelijk afhankelijk van nieuwe features van een taal. In plaats daarvan kan dezelfde functionaliteit worden geleverd aan een oudere versie van de taal door simpelweg de corresponderende code uit de nieuwe versie van de taal te kopi\u00ebren\/plakken\/aan te passen.<\/p>\n
De functie str_contains<\/code> werd bijvoorbeeld ge\u00efntroduceerd in PHP 8.0. Dezelfde functie kan eenvoudig als volgt in PHP 7.4 en lager worden ge\u00efmplementeerd:<\/p>\n
if (!defined('PHP_VERSION_ID') || (defined('PHP_VERSION_ID') && PHP_VERSION_ID < 80000)) {\n  if (!function_exists('str_contains')) {\n    \/**\n     * Checks if a string contains another\n     *\n     * @param string $haystack The string to search in\n     * @param string $needle The string to search\n     * @return boolean Returns TRUE if the needle was found in haystack, FALSE otherwise.\n     *\/\n    function str_contains(string $haystack, string $needle): bool\n    {\n      return strpos($haystack, $needle) !== false;\n    }\n  }\n}\n<\/code><\/pre>\n
Omdat backporten eenvoudiger is dan transpilen, is het slim om voor backporten te kiezen als dit de klus kan klaren.<\/p>\n
Wat betreft alles wat tussen PHP 8.0 en 7.1 komt, kunnen we de polyfill libraries van Symfony<\/a> gebruiken:<\/p>\n