Translation extractor crashes on PHP 8.4+ syntax (php-parser pinned to v4)

Summary

The PHP translation extractor cannot parse files that use PHP 8.4 syntax. Scanning such a file (e.g. via bin/console debug:translation or the back-office Export module translations action in a PrestaShop install) fails with:

Could not parse tokens in "<file>" file. Is it syntactically valid?

This is not a runtime problem — the code runs fine on PHP 8.4/8.5. It is purely the static extractor: its parser is a major version behind the language.

Root cause

Translation/Extractor/PhpExtractor.php builds the parser with the php-parser v4-only API:

$this->parser = (new ParserFactory())->create(ParserFactory::PREFER_PHP7, $lexer);

and composer.json pins nikic/php-parser: ^4. The v4 grammar only goes up to PHP 8.3, so PHP 8.4 constructs such as “new without parentheses” (new Foo()->bar()) cannot be tokenized. PHP 8.4 support landed in php-parser v5.

Impact

Any module/theme/domain file that adopts PHP 8.4 idioms silently breaks translation extraction for whatever is being scanned. Because PrestaShop core itself currently avoids 8.4-only syntax, this typically surfaces in third-party/custom code and is easy to misattribute to the module rather than the bundled extractor.

Reproduce

Run the extractor over a file containing:

<?php
$d = new \DateTime()->format('Y-m-d'); // PHP 8.4 "new without parentheses"

Proposed fix

Migrate the extractor to an API compatible with both php-parser v4.19+ and v5 (createForNewestSupportedVersion(), getStartLine(), Name::getParts()) and widen the constraint to ^4.19 || ^5.0, so that resolving php-parser to v5 enables PHP 8.4 parsing without breaking existing v4 consumers. PR follows.

Start with Translation/Extractor/PhpExtractor.php and composer.json, then inspect the current parser construction and compatibility APIs described in the issue. Verify the extractor against the PHP 8.4 example and confirm that dependency resolution supports php-parser v4.19+ and v5 without breaking existing behavior.