Add intl extension

[hellomohsinali]

function format_number(float | int $number): string
 {

        $formatter = new NumberFormatter(app()->getLocale(), NumberFormatter::DECIMAL);

        return $formatter->format($number);
}

format_number(2);

This code won't run as expected.

[MarceauKa]

Fixed it requiring symfony/polyfill-intl-icu

[buchin]

Fixed it requiring symfony/polyfill-intl-icu

Hi @MarceauKa, could you please elaborate required step to solve this issue?
I got this issue and requiring symfony/polyfill-intl-icu does not resolve it.

Thank you

[pmffromspace]

Hi I did a lot of research and this is the closest I got to an solution for this exact problem. Im trying to pack a filamenphp laravel webapp into a desktop programm with the help of nativePHP and I just cant find a way to remove the error „php extension intl not found“

@MarceauKa could you please just quickly tell us in which file (and maybe how) you fixed this?
I tried a lot of ways already, but Im unfortunatly new to php so I would really appreciate the help! :)

Kind regards

[simonhamp]

This is because the intl extension isn't built into the PHP binaries we're using yet.

I also noticed that it's apparently not available for Windows yet.

I will test and see what needs doing to get this in place on the binary side so we don't need to mess around with polyfills.

[pmffromspace]

Thanks for this quick response!

In the meantime I tried to build the php binaries manually with this approach:

composer require nativephp/php-bin --dev

git clone https://github.com/crazywhalecc/static-php-cli.git --depth=1
cd static-php-cli
bin/spc download --clean
bin/spc download --with-php=8.2 --for-extensions "intl,bcmath,ctype,curl,dom,fileinfo,filter,mbstring,openssl,pdo,pdo_sqlite,session,simplexml,sockets,sqlite3,tokenizer,xml,zlib"
bin/spc build --build-cli --build-embed "intl,bcmath,ctype,curl,dom,fileinfo,filter,mbstring,openssl,pdo,pdo_sqlite,session,simplexml,sockets,sqlite3,tokenizer,xml,zlib"

##-> copying to vendor directory...
# Doing the same for 8.3

bin/spc download --clean
bin/spc download --with-php=8.3 --for-extensions "intl,bcmath,ctype,curl,dom,fileinfo,filter,mbstring,openssl,pdo,pdo_sqlite,session,simplexml,sockets,sqlite3,tokenizer,xml,zlib"
bin/spc build --build-cli --build-embed "intl,bcmath,ctype,curl,dom,fileinfo,filter,mbstring,openssl,pdo,pdo_sqlite,session,simplexml,sockets,sqlite3,tokenizer,xml,zlib"

I then (Im on MacOS) right clicked the php bin and compressed it to a .zip file and renamed and replaced the supposingly old php bins at vendor/nativephp/php-bin/bin/mac/arm64/php-8.2.zip

But I stillt get the same error. (with php artisan native:serveor php artisan native:build)

Did I miss something when replacing the php binary or is it just not that simple?

Kind regards.

[simonhamp]

In theory, what you've done is correct...

What version of PHP are you running locally? php -v

[pmffromspace]

PHP 8.3.6 (cli) (built: Apr 12 2024 00:13:56) (NTS)

maybe I should zip it using a cli tool?

[simonhamp]

So the thing to check is if the PHP you've built actually includes intl

So you can check the PHP8.3 binary you generated:

/path/to/binary/php -i | grep intl

[pmffromspace]

I get following (I cant interpret if this is sufficient)

cd <directroy-of-generated-php-bin>
./php-8.3 -i | grep intl

Output:

intl
intl.default_locale => no value => no value
intl.error_level => 0 => 0
intl.use_exceptions => Off => Off

[simonhamp]

That means intl extension is enabled and working

[simonhamp]

It's possible that even after copying it into the vendor folder it gets wiped away

Can you also check the version that gets built into the app?

[pmffromspace]

Im having trouble finding a way to check that - in the developer tools I cant find the php version. Im also unable to build php-8.1.
How would I check the final build php version?

[simonhamp]

There are some instructions in the docs

[pmffromspace]

I was able to solve this issue 🚀with following steps thanks to the very helpful and kind person @simonhamp - many thanks!! (I will list all above discussed steps again so people stumbeling over it with the same issue have a better overview:

---

DISCLAIMER:

1. !! adapt the manual build to your php-version !!
2. I think this work around only works for the OS+Arch your manually building and replacing the php bin!

---

Setup:

• Filamentphp
• Laravel
• nativePHP
• basically the app enables users to input data into tables with the help of forms and displays them with charts on the app dashboard
  -> Trying to create a desktop app version off my laravel filament web app.

Problem:

• everything with nativePHP works fine, Desktop App starts and looks good.
• starting desktop app I sometimes got error code 500
• When user creates a entry (fills a form to add row to table) there is a fatal php error "php extension intl not found"

Cause:

the static php binaries currently used by nativePHP dont include this extension (yet)

---

Solution:

• basically I got it working by manually building the php binary and replacing the one used by nativePHP.

How I did this:

1. building php binary

• clone git for static-php git
• !! adapt to your php-version !!

composer require nativephp/php-bin --dev

git clone https://github.com/crazywhalecc/static-php-cli.git --depth=1
cd static-php-cli
bin/spc download --clean
bin/spc download --with-php=8.3 --for-extensions "intl,bcmath,ctype,curl,dom,fileinfo,filter,mbstring,openssl,pdo,pdo_sqlite,session,simplexml,sockets,sqlite3,tokenizer,xml,zlib"
bin/spc build --build-cli --build-embed "intl,bcmath,ctype,curl,dom,fileinfo,filter,mbstring,openssl,pdo,pdo_sqlite,session,simplexml,sockets,sqlite3,tokenizer,xml,zlib"

2. move php binary to nativePHP

• rename original /path/to/your/app/vendor/nativephp/electron/resources/js/resources/php/php
  to php.original

copy the newly built php binary from /static-php-cli/buildroot/bin/php to the nativePHP directory of your project /path/to/your/app/vendor/nativephp/electron/resources/js/resources/php/php

3. build with nativePHP

• run php artisan native:build and/or php artisan native:serve

---

i: Interestingly, it seems like the php binary gets copied from the dev to the prod build at dist so it seems to work.

verifying the build worked:

checking newly build php bin:

cd /static-php-cli/buildroot/bin/
./php -i | grep intl
./php -v

checking after 'php artisan native:build` run

# for DEV build
cd /path/to/your/app/vendor/nativephp/electron/resources/js/resources/php/php
./php -i | grep intl
./php -v

# for PROD build
cd /path/to/your/app/dist/mac-arm64/YOU_APP/Contents/Resources/app.asar.unpacked/resources/php/
./php -i | grep intl
./php -v

Helpful link to debug nativePHP related stuff: https://nativephp.com/docs/1/getting-started/debugging#check-your-app-and-php

[rogerznts]

I understand, I'm developing an application to solve my problem, without any great expectations. I'll continue exploring this combination, which is very interesting.

[simonhamp]

For the support.js issue, check here

[rogerznts]

@simonhamp awesome! Thanks

[kdrmlhcn]

I was able to solve this issue 🚀with following steps thanks to the very helpful and kind person @simonhamp - many thanks!! (I will list all above discussed steps again so people stumbeling over it with the same issue have a better overview:

DISCLAIMER:

1. !! adapt the manual build to your php-version !!
2. I think this work around only works for the OS+Arch your manually building and replacing the php bin!

Setup:

• Filamentphp
• Laravel
• nativePHP
• basically the app enables users to input data into tables with the help of forms and displays them with charts on the app dashboard
  -> Trying to create a desktop app version off my laravel filament web app.

Problem:

• everything with nativePHP works fine, Desktop App starts and looks good.
• starting desktop app I sometimes got error code 500
• When user creates a entry (fills a form to add row to table) there is a fatal php error "php extension intl not found"

Cause:

the static php binaries currently used by nativePHP dont include this extension (yet)

Solution:

• basically I got it working by manually building the php binary and replacing the one used by nativePHP.

How I did this:

1. building php binary

• clone git for static-php git
• !! adapt to your php-version !!

composer require nativephp/php-bin --dev

git clone https://github.com/crazywhalecc/static-php-cli.git --depth=1
cd static-php-cli
bin/spc download --clean
bin/spc download --with-php=8.3 --for-extensions "intl,bcmath,ctype,curl,dom,fileinfo,filter,mbstring,openssl,pdo,pdo_sqlite,session,simplexml,sockets,sqlite3,tokenizer,xml,zlib"
bin/spc build --build-cli --build-embed "intl,bcmath,ctype,curl,dom,fileinfo,filter,mbstring,openssl,pdo,pdo_sqlite,session,simplexml,sockets,sqlite3,tokenizer,xml,zlib"

2. move php binary to nativePHP

• rename original /path/to/your/app/vendor/nativephp/electron/resources/js/resources/php/php
  to php.original

copy the newly built php binary from /static-php-cli/buildroot/bin/php to the nativePHP directory of your project /path/to/your/app/vendor/nativephp/electron/resources/js/resources/php/php

3. build with nativePHP

• run php artisan native:build and/or php artisan native:serve

i: Interestingly, it seems like the php binary gets copied from the dev to the prod build at dist so it seems to work.

verifying the build worked:

checking newly build php bin:

cd /static-php-cli/buildroot/bin/
./php -i | grep intl
./php -v

checking after 'php artisan native:build` run

# for DEV build
cd /path/to/your/app/vendor/nativephp/electron/resources/js/resources/php/php
./php -i | grep intl
./php -v

# for PROD build
cd /path/to/your/app/dist/mac-arm64/YOU_APP/Contents/Resources/app.asar.unpacked/resources/php/
./php -i | grep intl
./php -v

Helpful link to debug nativePHP related stuff: https://nativephp.com/docs/1/getting-started/debugging#check-your-app-and-php

I solved problem on MacOS but it still exists on Windows. Is anyone solved this issue on Windows? @simonhamp @pmffromspace

[danie1net0]

I'm on MacOS and reproduced these steps, but they didn't solve the problem. I copied the PHP bin from /opt/homebrew/Cellar/php/8.4.2/bin/php to vendor/nativephp/electron/resources/js/resources/php/ and this is the output when I run the command ./php -i | grep intl:

intl
intl.default_locale => no value => no value
intl.error_level => 0 => 0
intl.use_exceptions => Off => Off

But when I open the Filament listing page, the error continues.

[robot-iraq]

I was excited to discover this tool, but the PHP development experience on Windows is far from ideal. It's not just the "intl" extension that's essential for PHP development—other critical extensions like PCNTL, which is used in Horizon, Octane, and Laravel's concurrency features, are also unavailable on Windows. Unfortunately, I don’t see any support or implementation for these extensions coming anytime soon.

[danie1net0]

Actually Windows can't provide you a good PHP development experience in general.

[robot-iraq]

well, is it the OS responsibility, or the language?

[simonhamp]

pcntl is a very rich and robust abstraction over key process management features of *nix-like operating systems. Windows completely lacks this level of robustness by default.

So for that one, it is the OS's fault and really Microsoft's responsibility to provide better tooling there that is on par with the industry standard.

Maybe WSL2 goes some way to helping, but running applications that rely on that feels brittle at best.

The lack of intl is just a result of not finding the right path to compile it statically for Windows yet, and is neither a language nor OS problem - it's just a combination of things that very few people have tried to tackle.

[Mghobadid]

Workaround to Bypass the Intl Extension Check in Laravel Number Helper (For Windows Users)

For anyone facing this issue on Windows, I came up with a (call it "bad but working") way to bypass the intl extension check used in Laravel's Number Helper. This helper was added to Laravel starting from version 10.33.0, so if you are using that version or higher, you might not face this problem.

In this temporary workaround, we trick the PHP interpreter into assuming that the intl extension is loaded!

⚠️⚠️ Attention: ⚠️⚠️

This method could potentially harm your application and introduce risks, so use it only if you 100% understand what you're doing. By bypassing this check, you are essentially telling the application that the intl extension is available, even if it isn't, which can lead to unexpected behavior in other parts of the framework or packages that rely on it.

Here's how it works:

Create an Override for the extension_loaded function: We define a custom version of the extension_loaded function inside the Illuminate\Support namespace, which forces it to always return true when checking for the intl extension.

Load the Override Before Laravel's Core: The trick is to load this override file before Laravel’s autoloader. This ensures that whenever the Number Helper (or any other part of Laravel) checks if intl is loaded, our custom function is used.

Test Carefully:
Ensure that this doesn't break any other functionality, especially parts of the framework or third-party packages that rely on the actual availability of the intl extension.

The Override Code:

<?php
// app/Overrides/intl_override.php

namespace Illuminate\Support;

if (! function_exists('Illuminate\Support\extension_loaded')) {
    function extension_loaded($name)
    {
        if ($name === 'intl') {
            return true; // Assume intl is loaded
        }
        return \extension_loaded($name); // Call the original function for others
    }
}

Then, in your public/index.php, include this file before Laravel's autoloader:

<?php
// public/index.php

// Preload your override for extension_loaded in the Illuminate\Support namespace.
require __DIR__ . '/../app/Overrides/intl_override.php';

require __DIR__ . '/../vendor/autoload.php';

// ... rest of your bootstrap process

Final Thoughts:

• Use With Caution: This is a hacky solution that forces Laravel to ignore the missing intl extension, but it's not a sustainable or recommended practice. Only use this if absolutely necessary, and test your application thoroughly.

• Risk Assessment: If Laravel or any package relies on the actual functionality of the intl extension, this could cause unpredictable behavior.

• Future Improvements: I believe the final and proper workaround would be to load the intl.dll dynamically into static PHP. Unfortunately, I haven't been able to implement this solution yet, but it could potentially provide a more stable and permanent fix.

[binaryfire]

I just saw this comment in the static-php-cli repo: crazywhalecc/static-php-cli#435 (comment). Does that mean it's now possible to add it for Windows?