collect() helpers accepts arguments other than iterables leading to unexpected behaviour in case of an oversight

[michapietsch]

Laravel Version

12.30.1

PHP Version

8.3.24

Database Driver & Version

No response

Description

I ran into a bug when I tried to spread two arrays into a new collection like this:

collect(
    ...[1, 2],
    ...[3, 4]
)

The result is equal to collect(1).

I simply forgot the surrounding [].

I see a chance to improve developer experience here: Communicate that the helper is being used wrong.

After all the helper is declared to accept:
@param \Illuminate\Contracts\Support\Arrayable<TKey, TValue>|iterable<TKey, TValue>|null $value.

But it accepts e. g. 1 which is neither of these, and it silently omit the additional arguments from the array spread.

I suggest the helper could throw an invalid argument exception for non-iterable values, and/or throw when more than one argument is passed.

PHPstan requires levels 9 to catch such things.

Steps To Reproduce

In Tinker run:

collect(
    ...[1, 2]
)

The output will be:

Illuminate\Support\Collection {
    all: [
        1,
    ],
}

[shaedrich]

This is not an issue of the helper per se but lies in getArrayableItems() accepting scalar inputs:

framework/src/Illuminate/Collections/Traits/EnumeratesValues.php

Lines 1062 to 1073 in 7514188

	/**
	* Results array of items from Collection or Arrayable.
	*
	* @param mixed $items
	* @return array<TKey, TValue>
	*/
	protected function getArrayableItems($items)
	{
	return is_null($items) || is_scalar($items) || $items instanceof UnitEnum
	? Arr::wrap($items)
	: Arr::from($items);
	}

To solve this, you could create a PR targeting master adding native argument types rather than PHPDoc block types to 13.x, but this looks like it's intended to work that way, so I wouldn't assume, this PR would go through.

In that case, I doubt, runtime checks are really a solution here. You might have more luck with static analysis tools like Rector