Yes, sometimes such solutions look absurd. But they are needed to remind us that hardcoding is a powerful performance optimization tool.

For me this is legit thing.
Writing code to generate list, properly process list
and implement it requires much more
work then just solving.

thx)

Great solution. Easy to understand.

/\d\d\d|\d\d|\d/g can be replaced with /\d{1,3}/g

Yet another comedy.

When did Codewars become a comedy show?

You can use ESLint or Prettier to achieve this format.

Haha. What a joke!

Thumb down 👎

In my understanding, this kata doesn't put any restriction on the input strings. So, 'abc' and 'c' are both valid strings. And what I want to comment is the RegEx solution can't cover special cases.

Edit: Oh, now I understand that this RegEx solution is for the old version of this kata, and it was correct. Now the kata has changed, and it's no longer accurate. Anyway, I think we can update the test cases, but the kata's original description should not be changed. Otherwise, the solutions won't be consistent.

Correct, it'll fail.
The author should have added that to the list of test-cases earlier (perhaps to intentionally escape weird inputs).
It's not hard to either use endsWith (if available) or implement a trivial linear (O(n)) solution that scans each character from the end of the string.
The latter could be then optimized by splitting the ending into two halves and checking first and last characters for each half (that way it'll give negative response faster than a linear solution).
Just for your information, 'abc' and 'c' are both incorrect string literals since they should end with an additional apostrophe.

This solution is not correct for special cases such as:

solution('ab(c)', '(c)');

solution('abc\', 'c\');

solution('abc+', 'c+');