splitWordsRegex fails on iOS 16 about moderndash HOT 6 CLOSED

@acorn1010

The issue got autoclosed with merging the PR.
I added a fallback for browsers that don't support positive lookbehind in regex. Let me know if it works! :)

We can still discuss if it makes sense to modify inputs in merge.

from moderndash.

Sorry about the original RegEx—just noticed there were tests! This one should cover everything in the tests, plus some other edge cases like "enable6HFormat" -> ["enable", "6H", "Format"] while still maintaining a small file size:

const splitWordsRegex = /(\d*[a-z]+)|([A-Z][a-z]+)|(\d*[A-Z]+(?=[^a-z]|$))|(\d+)/g;

(I got the enable6HFormat from here: https://github.com/lodash/lodash/blob/4.17.11/test/test.js#L2351)

P.S. The fallback works!

from moderndash.

Thanks, this is a much simpler solution. I deployed it in 3.3.1. It is 10% slower than my lookbehind solution, but the
"enable6HFormat" -> ["enable", "6H", "format"] case was handled differently. It makes sense to match lodash's behaviour and its still 2x faster. 🥳

from moderndash.

Hi @acorn1010, thanks for the suggestion. I will answer this step by step. Your regex doesn't account for this case:

AssertionError: expected 'some_cruelw_orld' to be 'some_cruel_world' // Object.is equality
 ❯ test/string/snakeCase.test.ts:10:45
     10|         expect(snakeCase('someCRUELWorld')).toBe('some_cruel_world');
       |                                             ^
     11|     });
     12|

  - Expected   "some_cruel_world"
  + Received   "some_cruelw_orld"

But I agree that we should at least make it compatible with Safari 15. I will see what good replacements are out there when I have the time.

from moderndash.

range(0, 3) is inclusive instead of exclusive (e.g. returns [0, 1, 2, 3] instead of [0, 1, 2]). This is different from Lodash and caused some bugs.

I decided to do this to have a more readable syntax. All ranges in moderndash include the last parameter. In randomInt and randomFloat the last parameter is also included in the range.
ModernDash is not intended to be a drop-in replacement. Instead, I tried to make the syntax as readable as possible. Therefore I would like to keep the range function as it is.

from moderndash.

@acorn1010 opened a new issue for the array mutations, where we can discuss this further. ⬆️

from moderndash.