Fix ScalaJS regex and regression tests

[pablf]

/claim #2707

[987Nabil]

@pablf This solution changes what is checked by the regex. To avoid this we discussed in the issue to use an alternative to regex, like rich text codec from zio-http. As @jdegoes added $250 bounty I expect that is what he was aiming for as well.

[pablf]

@987Nabil Would you mind expanding what is different between those two regex? I really don't mind using the RichTextCodec approach, but before the PR I spent some time trying to understand why this approach was too naive to work but wasn't able to see it 😅.

My reasoning is that matching a regex always applies to the full string, unless explicitly unanchoring it using .unanchored. In this case, in which there is only a match (find methods could match only part of the expression but is not the case), adding ^ and $ at the start or the end of the pattern is redundant as it's already checked by the pattern match unless using unanchored on the regex. Also, the fact that s"""^(?i)([a-z0-9]+)(?:/([a-z0-9.]+))(.*)$$""" can be changed to "^(?i)([a-z0-9]+)(?:/([a-z0-9.]+))(.*)$" without changing the regex and the string interpolation is not really needed, made me think of some possible bug.

Please correct me if I'm wrong, but I don't really see what is failing here 😅. Also, if this modified regex were wrong, I don't see why a really equivalent regex should automatically be discarded. I didn't see this discussed in #2707, so maybe there is also some benefit to RichTextCodec that I don't know.

[987Nabil]

@pablf actually I think you are right. There is nothing that makes it match on a sub string like surrounding .* . Maybe it is okay like that.
I am not 100% sure, but I could imagine that rich text codec could be more perfomant if done right. But I am not sure as well. Maybe the solution is okay.

[pablf]

@987Nabil I've tried to compare both methods: https://scastie.scala-lang.org/KKXGXYeWSTednuDTCXiCfQ. It's a bit messy, but hope it's helpful.

Not too different, although Regex seems 2x faster when matching and RichTextCodec sometimes fails faster (in JVM). The relevant comparison for this particular case would be Comparison 5. Also, there might be better designed RichTextCodec that would perform better than the ones I made...