Array mapping issue after upgrading from 9.2.0 to 9.3.0+: elements start wrapping into subarrays

[Badrutdin]

After upgrading the jolicode/automapper package from version 9.2.0 to 9.3.0 (and higher), the behavior when mapping array properties changed.

Instead of copying the array as is, each array element is now wrapped in an additional subarray.

This change is not documented or mentioned in the changelog/release notes.

Example:

$productVariant = $this->autoMapper->map($dto, ProductVariant::class);
$this->assertEquals($dto->optionValueIds, $productVariant->getOptionValueIds());

DTO:

/** @var string[] */
public array $optionValueIds = [];

Entity:

/** @var string[] */
public array $optionValueIds = [];

Result up to 9.3.0 (correct):

['val1', 'val2', 'val3']

Result after 9.3.0 (incorrect):

[['val1'], ['val2'], ['val3']]

Additional Information:

The issue has been present since version 9.3.0.
Version 9.2.0 works correctly.

The issue persists even when using a simple string array—without nested structures, custom transformers, or any special configuration.

What we discovered

• Analyzing the generated proxy classes (var/cache/dev/automapper) reveals that array transformation occurs during the execution of the generated code.
• This behavior is related to changes in ArrayTransformerFactory, where new logic is used instead of using CopyTransformer.
• Adding a custom transformer doesn't solve the problem—it works correctly, but at a later stage, the data is transformed again.
• The problem disappears if you explicitly specify a PHPDoc annotation with the array element type in the entity setter:

/** @param string[] $optionValueIds */
public function setOptionValueIds(array $optionValueIds): self
{
    $this->optionValueIds = $optionValueIds;
    return $this;
}

Without this annotation, Automapper incorrectly determines the type of array elements and creates subarrays.

This issue is critical for projects that make extensive use of arrays of simple types (string[], int[]) and JSONB fields, as in these cases the mapper's behavior is systemically disrupted.
Perhaps it's worth considering implementing backward compatibility or documenting the need to specify the @param annotation for arrays in setters.