Wow!
You definitely have a great understanding of RegExp.

This is good. You can make it a bit more concise if you update the regex from what you have to "/[105]/g".
This uses a character class, so for every character Regex looks at, it looks see if the character is either "1", "0", or "5".

This is an interesting use of a For loop inside of a Map call.
For me, the only that would make this clearer would be to rename the "len" variable to "count" or something similar.
"len" makes me think that the variable references an Array's "length".

Doh. I could have just returned "a" for the ternary's false side.

Dang. I always forget about using the spread operator to make a shallow copy of an array. Good job.

I agree that we should always try to leverage TypeScript's types. For instance, this function's signature could be more strict with its typing. But those types go away at runtime.
I believe we should still, at the very least, protect against predictable type errors such as calling "filter" on a string. Because a consumer may still send a string.

My perspective is coming from API development. But if we're talking about an arrangement of code and modules where the developer has complete control over inputs, I'd agree more with leaning into typing over runtime checks.

Unfortunately I don't think this is good advice. It's technically correct, yes, but being able to constrain the type of some variable is the entire point of TypeScript. Our first suggestion here should be to use that capability, not to improve our runtime type checks.

Array.isArray() would be a safer check for an Array here, since Strings also have "length" as a property.

:) You're welcome!

Ha! I didn't even notice the parameter ordering in Reduce.
And that's an awesome reference sheet. Thank you for sharing.

Thanks! You could still use parseInt and parseFloat, or "+" depending on the use case (i.e. parsing strings with non-numerical characters vs. parsing hex values), but I find "+" convenient for working with TypeScript in general.

Here is a helpful table for reference:
https://i.stack.imgur.com/QNMfI.png

*Lol at second glance it appears I accidentally flipped the params in reduce. Should be:
.reduce((acc, n) => acc + n)

That's fantastic use of the "+" unary operator.
No need for parseInt or parseFloat!