Resolved with update fork to Node 18

It's an error to me simply because authors/translators should never be rolling their own shuffle/random when we have lodash available for JS, I'll change it.

There is no reason for the "for in" not to work here, even if other constructs are available. This is a kata issue, not a user issue.

Yes, extending built-in types should be avoided, but let me ask again: isnt it that a programmer who decided to use for...in does things incorrectly, because the for...in simply does not work in a way which allows to iterate over arrays (or anything else) reliably? By using potentially misbehaving features, user brings the problem on themselves - especially in face of the fact that there are easily available replacements which work correctly (like for...of).

I still think that using a wrong language construct (i.e. for...in) is solver's error, unless, for some reason, for..in (i.e. "iterate over all existing keys") would be the solution for this problem, but I don't think it is?

I agree with hobovsky here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in#array_iteration_and_for...in

I might be not a JS person, but I think that for...in should not be used for exactly this reason, and should be replaced with for...of?

let arr = ['a', 'b'];
Array.prototype.shuffle = () => {};
for (let i of arr) { console.log(i); }
// console:
// a
// b

I think it's not a kata issue, but a misuse of a language feature? Unless, for some reason, you need to iterate exactly over indices and not actual values? Is this a case in this kata?

Empty string is a special case which doesn't really make sense in a reader.
But anyhow, that would means nothing, thus :

      test4:
      {
        text: "",
        words: 0,
        chars: 0,
        lines: 0
      }

i do agree this is in conflict with the "Returns at least one char" instruction
(i don't remember if this was in the description i specified 9 years ago or if someone added that line since then)
but defensive programming is always recommended and those values are easily testable

as soon as there is one char, you get a line and a word

      test5:
      {
        text: "A",
        words: 1,
        chars: 1,
        lines: 1
      }

but there is a special weird case, what if the text as chars, but it only contains spaces ?
...
there is no word!

      test6:
      {
        text: " ",
        words: 0,
        chars: 1,
        lines: 1
      },

Unfortunately that's how CW test runner is written, so I can't overwrite it ;-)

Unfortunately not. And I can't find a good fix to cheats like this, so I'll have to leave it as is ;-)

Probably the easiest way to think of it is to ask the question: how many hours are between one o'clock and five o'clock?

@OverZealous gave a great explanation, thanks!

[1, 5] is an interval from 1 to 5, not 1 to 4. It starts from 1, and ends at 5 (includes both). Think of [1, 5] as 4 pieces that are of length 1 each, like: [1, 2], [2, 3], [3, 4], [4, 5]. It's not asking how many integers there are in [1, 5]

I suppose it's mostly in how you look at it. Since we're looking at intervals (length), rather than sets, think of it like this:

Interval length
   1   2   3   4   5
 |-^-|-^-|-^-|-^-|-^-|
 0   1   2   3   4   5
Endpoints

Another way of looking at it, if you have a string that is between 2 and 5 units on a ruler, then that string is 3 units long, not 4.

Overlapping example:

 1   2   3   4   5   6
 |---|---|---|---|---|
     •-------•
         •-----------•

Total length is 2-6, or 4 units.

First value (integer 1) is included in the interval, while the second (integer 5) is not. This is also the reason [1,5] and {5,10] do not overlap :)

Okay; I've cracked it. Thanks for your help and patience. I might be inclined to add to or change the description to make this all more clear, but only if you want to. An interesting kata, this. I don't know much about the inner workings of TCP and such, so this is pretty cool.