Fix "Array to string conversion" for Symfony 7.4+ compatibility

[MrShefter]

Description

This PR fixes a Warning: Array to string conversion that occurs when using liuggio/fastest with Symfony 7.4 or higher.

The issue:
Since Symfony 7.4, the Symfony Runtime component exposes new entries in $_SERVER, specifically APP_RUNTIME_OPTIONS. This entry is an array.
When EnvCommandCreator::execute merges $_SERVER into the environment variables for the subprocess, it includes this array. Later, when Symfony\Component\Process tries to start the process, it iterates over these variables and fails because it attempts to concatenate an array as a string:

// Symfony\Component\Process\Process.php
$envPairs[] = $k.'='.$v; // Error here if $v is an array

The fix:
I updated EnvCommandCreator to filter out any values that are arrays. Environment variables should fundamentally be strings; passing an array through the environment is not supported by the underlying OS/process components anyway.

Changes

• Modified Liuggio\Fastest\Process\EnvCommandCreator::execute to skip elements where the value is an array.

[DonCallisto]

Tests that are failing but your assumption about the type is correct as env handles only string|Stringable.
Please fix them accordingly, then I'll be happy to merge it.

Thanks.

[MrShefter]

@DonCallisto It's good, thanks for you reactivity !

[DonCallisto]

I was wondering if it should be better to "decompose" the array instead of skipping it altogether.
Something like a recursive process to extract array entries as single values.

Reasoning not about that Symfony specific case where, maybe, it is fine either way, but more in general, I think it would be sensible to do so. WDYT?

[MrShefter]

I understand your point of view. However, I see a few limitations with that approach.

• First, we could face key collisions if a key generated from the decomposition already exists in the main array.

• Second, even if we decompose the keys, Symfony won't be able to interpret them correctly because the resulting key names will no longer match what the framework expects.

Another alternative could be to json_encode the array values. This would preserve the data as a string, which is compatible with environment variables. However, the subprocess would still need to be aware that it needs to json_decode that specific entry to use it.

[DonCallisto]

First, we could face key collisions if a key generated from the decomposition already exists in the main array.

We could still face them as we're not controlling $_SERVER (just to take this only) content

Second, even if we decompose the keys, Symfony won't be able to interpret them correctly because the resulting key names will no longer match what the framework expects.

Not sure about that. I mean, I don't know how symfony will look after them and we don't need to care about it. You can see this as a "best effort" logic: instead of get rid of 'em, try to provide a sensible list.

The more I think, the more I'm convinced we should not skip those values.

[MrShefter]

I have updated the code to implement the array decomposition as discussed:

decomposeRecursively: Instead of skipping nested arrays, this method flattens them into prefixed keys (e.g., APP_RUNTIME_OPTIONS_project_dir).

formatValueForEnv: This ensures every value is a string. It handles scalars, converts stringable objects via __toString().

I hope this version works for you.

[DonCallisto]

I've just released a new version https://github.com/liuggio/fastest/releases/tag/v1.14.1

I was not convinced about carrying around "prefixes" for those arguments but I didn't had a strong opinion or specific use case to ask for a change.

Thanks for your contribution.