Note: If the input string contains no digits, this solution will return a 0, which might be unexpected behavior. By contrast, parseInt() and unary + coercion will result in NaN.

Just for curious newbies, this approach bug-prone because it will fail without throwing an error if the first string contains a space character already.

In order for this solution to work reliably, it must use a delimiter which is guaranteed to be absent from the source strings.

This was fun to solve in JS without recursion or mutating the nodes. This kata has good potential as an opportunity to practice generators.

It seems to default to the latest, though I can't be 100% sure without starting a new account.

In general, I'd like that too. My only concern is that if it selects node 8 by default, then it's not ideal :p

The pattern I've seen is that they generally keep the older versions enabled.

Done. I'm not sure if it's gonna auto-select the latest version from now on, or if I should disable the others.

It would be really nice to update the Node.js version for this kata.

Fixed

Fixed.

Useful information. :) Thanks!

On further experimentation, there are definitely JS test cases which expect the output to be -0 when both the multipland and multiplier are positive numbers.

In one random test case, for example, n (the multiplicand) is 291 and the first integer in the array (the multiplier) is 0. The test is failing because it says that the result of that first multiplication is expected to be -0.

If we could expect all such cases (where the multiplicand and multiplier are both positive) to result in a negative zero for some reason, then fine: we could work around it sensibly. But not all the test cases expect negative zero in this "positive times positive" scenario.

Right now, this kata as described seems unsolvable in JavaScript. Perhaps the description needs updated if there is some implicit requirement for returning negative zero in certain conventionally-unexpected cases. But more likely, there is a bug in the test solution.

Why are we still getting -0 in the "expected" results in this kata, particularly in JavaScript?

It's not even conventionally possible to check for -0 in JavaScript using operators, Math.sign(), or the rest of the Math library, as far as I can tell. You can't even use right-shift to find that.

(I can find two ways to do it, but they are both highly obscure and one of them appears to be undocumented. I will mention them in a comment below with a spoiler tag for those interested.)