Nice decision to extract geese from a function to not recreate it each function's call

To learn the built-in functions. 🪿

What is the purpose of the test, if you use built-in functions?

Why didnt you had to return 0 in case the array is empty?

Why replicate Python's range in any language at all? Especially given its behavior is nonsensical.
I've seen plenty of katas about implementing built-in features (without using the existing ones of course) so your question is not as rethorical as you seem to believe.
Have a nice day.

Why would you replicate Python's range in Python? It's already a built-in there. That makes less sense to me. Yes, I agree it's confusing, but you only can assume if you receive two arguments, they're the first 2, and never the last 2 (just like Python's range).

Sorry, but while the Python range function has weird semantics, it does not in any way justify a signature like function(optional_argument, required_argument, optional_argument)...

It is very strange to want a function to have optional arguments that do not come last.

Say I call range(a, b)... Is the first optional argument omitted? Or the third one? How would you tell?

Just because the Python range function is messed up and makes very little sense and cannot be improved because retro-compatibility is vital... does not give this kata any value. Especially with other languages in the mix.

Say I really go out on a limb and make language semantics allowing ANY argument to be optional....
Then I could write this:
my_wonderful_function = (optional_arg1 = default_arg1, required_arg2, optional_arg3 = default_arg3) {...}
But then what if someone calls my_wonderful_function(0, 2)? Is it arg1 = 0 and arg2 = 2, or arg2 = 0 and arg3 = 2?

Optional parameters which go before required parameters make NO sense. Even less so in a language like JavaScript which treats undefined, null, 0, '', and [] as similar unless you ask for a super strict comparison.

TL;DNR: if the point was to reproduce the very weird behavior of Python's range function, maybe it should have been restricted to Python (or forgotten entirely and never made into a kata).

Optional arguments always come last.

i just understood what was the problem, thx

I don't know what you mean, you have this line: if(step == 0){return 2} and one test fails with this error message: Test failed for range(0,2,0): expected 2 to deeply equal [ 0, 0 ] so it's not ignoring it as you say it does.

when step equals 0, it just ignores console.log(step
WHY?

But why it just ignores the 'if(step == 0)'?!?!

It looks very similar to the range function from python to me (excluding the step = 0 case).
So I don't think it is that strange to want such behavior.

# python 3
>>> list(range(10))
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> list(range(5, 10))
[5, 6, 7, 8, 9]
>>> list(range(5, 10, 2))
[5, 7, 9]
>>> list(range(10, 5))
[]

Who in their right mind would decide to make the first argument optional but not the next one?

If start is optional and not stop, then the proper signature should be range(stop, start = 0, step = 1).

Also the behavior for step = 0 or start > stop make zero sense to me.

Isn't it? I mean, sure, the author didn't do their homework and plan for malicious compliance in their tests... but the instructions say it's a 2D-array, not a 8x8 chess board.