the description does not specify which group of consecutive zeroes to compress when there are several groups tied for the longest sequence

RFC 5952 does say:

When the length of the consecutive 16-bit 0 fields
are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero
bits MUST be shortened. For example, 2001:db8::1:0:0:1 is [the] correct
representation.

Yes, I mean the latter. Many solutions only perform a singular assertion check for that specific fixed test only.

Also, random tests should generate such cases, if possible shuffle and mix with other grouping of cases in which zeros appear in the middle (see below).

AFAIK a contracted IPv6 form has no :::, the only contracted form is two colons, isnt it?

https://en.wikipedia.org/wiki/IPv6_address#Representation

Unless you mean the validation part and using ::: as invalid input?

Description should be language-agnostic

Missing sample and fixed tests for consecutive colons of longer than 3, i.e,

• 0101:::::::

• :::::0:1:0:1

• 0A0B:0C0d::::28c1:1:2

etc...

The case with single group of zeroes appearing in the middle (instead of the ends) of a IPv6 address is missing in the fixed tests (when everything else is included in the fixed tests). It's only in the random tests.

The kata is stuck at Node 8.

IPv4 address component in IPv6 isn't tested.

Every IPv6 kata kinda expects incorrectly contracted IPv6 address as input to be treated as valid, so...

"Javascript's array.splice() function is terrible"? Really? I was quite happy, finding out it can do exactly what I was looking for :-) Thumbs up for the comments!

Great!

awesome solution

Yes there are, but they are already compressed. Note the "::" in the inputs.

B090:2985:9000::6F39:00 -> expected 'b090:2985:9000::6f39:0'

A01C:BA::140C:D:0640:002D -> expected 'a01c:ba::140c:d:640:2d'

There aren't two consecutive groups of just 0 in either of these inputs, why are they valid?

WHen you have more than 2 consecutive groups of just 0, e.g. 1:0:0:0:1 -> 1::1.