_.kebabCase and _.camelCase treat some digits as delimiters but not others

[olexpono]

Issue

Sets of digits \d+ ending 1,2,3 in a part of a string introduce a delimiter when processed with lodash kebabCase and/or camelCase. This behavior seems to be built around the logic of 1st, 2nd, 3rd, Nth but it's not documented and fails for teen numbers -- e.g. 11 or eleventh is expected to be 11st in lodash.

/* Kebab case, '-' introduced */
11th place      -> 11-th-place
1111th place    -> 1111-th-place
12th place      -> 12-th-place

/* Camel case, 't' is capitalized */
11th place      -> 11ThPlace
1111th place    -> 1111ThPlace
12th place      -> 12ThPlace

Meanwhile, sets of digits ending in 0,4..9 do not introduce delimiter:

/* Kebab case, no '-' between number and `th` */
14th place      -> 14th-place
1234th place    -> 1234th-place
17th place      -> 17th-place

/* Camel case, 't' not capitalized */
14th place      -> 14thPlace
1234th place    -> 1234thPlace
17th place      -> 17thPlace

---

Is this intended and should it be documented?

I'd be happy to add some tests and resolve this in either direction, but it seems like the testing facilities are not currently available in the main branch & I'm not sure how to run the test suite. Any pointers to a newer Contribution guide or a specific fork/v5 branch to look at?

---

Additional Quirks

The delimiter / no delimiter cases also differ by the text adjacent to the numbers:

[DaviVilarinho]

I think it is intended, my friend.

Look at camelCase.ts, it calls the words function, that is defined in words.ts, WITHOUT any pattern at all (check that there is a replacement by a pattern, not a function call with a pattern).

Meanwhile, words function with undefined pattern can return unicodeWords, and that has regex checks such as:

const rsOrdLower = '\\d*(?:1st|2nd|3rd|(?![123])\\dth)(?=\\b|[A-Z_])'
const rsOrdUpper = '\\d*(?:1ST|2ND|3RD|(?![123])\\dTH)(?=\\b|[a-z_])'