Call to undefined function JmesPath\mb_strlen() about phpbu HOT 5 CLOSED

Actually, I believe I have found the reason: The Polyfill seems not to be included in the final phpbu.phar distribution file:

phar list -f phpbu.phar | grep polyfill-mbstring
# 0 results

I believe the Phar file is built by copying dependencies over via a "whitelist":

E.g.: The current distribution only contains symfony/options-resolver, but not the other symfony/* dependencies, such as the polyfill:

• deprecation-contracts
• polyfill-ctype
• polyfill-mbstring
• polyfill-php80
• process
• var-dumper

I am not sure why the dependencies are copied one-by-one, rather than adding all of them. Perhaps distribution size? But even then I would guess adding everything and then removing the ones that are definitely not needed (aka. blacklist rather than whitelist) would make for more stable release package while keeping release sizes reasonable.

from phpbu.

possible solution here:
https://stackoverflow.com/questions/6419102/fatal-error-call-to-undefined-function-mb-strlen

from phpbu.

Hm, this puzzles me a bit. Can you provide more information on the type of environment you run phpbu in: PHP version, OS, Shared Hosting, phpbu version, ...?

This usage of mb_strlen comes from a transitive dependency: phpbu uses aws/aws-sdk-php, which uses mtdowling/jmespath.php, which uses mb_strlen. However, that last one also requires symfony/polyfill-mbstring, which should transparently add the function in the global namespace, if it doesn't exist. So I am wondering how we're even getting to this message...

from phpbu.

Well, is a VPS with docker and no public php server. So the php installed there is the default ubuntu one, which lacks the mbstring.
Installing apt-get install php7.4-mbstring solve the issue and works, but yeah, I wondered the same thing.

Ubuntu 22.04, php 7.4, latest phpbu version. VPS.

from phpbu.

Yes the main reason for the whitelist was file size at some point.
But I think changing it to a blacklist would be the better option.
That does not remove the burden of knowing every dependency that goes into the PHAR.
The Symfony polyfills are a good example. Including the classes into the PHAR is not enough.
The polyfill setup hast to be manually called within the PHAR

    // load the symfony polyfills
    require __PHPBU_PHAR_ROOT__ . '/lib/symfony/polyfill-ctype/bootstrap.php';
    require __PHPBU_PHAR_ROOT__ . '/lib/symfony/polyfill-mbstring/bootstrap.php';
    require __PHPBU_PHAR_ROOT__ . '/lib/symfony/polyfill-php80/bootstrap.php';

I think 470ab12 fixes the issue

from phpbu.