Feature Request: CamelCase to behave like lodash.camelCase and camelcase

[gCardinal]

Right now, CamelCase (and, obviously, CamelCasedProperties and CamelCasedPropertiesDeep) behaves weirdly when handling two character strings.

When it's a 2 character string (like ID, for example), it will transform the string as expected (ID to id), but strings like HostIDPlayer will leave the ID part untouched (HostIDPlayer to hostIDPlayer).

const a: CamelCase<'ID'> = 'id';  // Works, no TS error 
const b: CamelCase<'HostIDPlayer'> = 'hostIdPlayer';  // Error, TS expects 'hostIDPlayer'

Libraries like lodash.camelCase and camelcase will transform the strings as expected as can be seen in this codesandbox.

I can't say I know enough about TS' type system, but is there a way to make CamelCase behave like lodash.camelCase and camelcase? That was, to me, what I expected the behavior to be.

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• The funding will be given to active contributors.
• Thank you in advance for helping prioritize & fund our backlog.

[sindresorhus]

I agree with you. It's how I prefer doing camel-case. But there are definitely some people that prefer the existing behavior...

For example, the camelcase package has an option to enable the current behavior: https://github.com/sindresorhus/camelcase#preserveconsecutiveuppercase

@wwwzbwcom Thoughts on this?

[wwwzbwcom]

Maybe add a option to toggle it?

[voxpelli]

Right, as CamelCase<> is currently implemented, it:

• Splits words separated by -, _ or a white space
• It lower cases the first character always
• If all characters in the input are upper case, then prior to doing anything, they are all lower cased

It does not split on uppercase characters in any way, unlike the DelimiterCase based ones.

Though the DelimiterCase ones would probably also not handle this very well, eg. KebabCase<'HostIDPlayer'> would probably give a string literal that's 'host-i-d-player'.

Currently CamelCase does look at the previous character when it decides what to do, but currently DelimiterCase doesn't.

To support this use case I think we essentially would have to merge the functionality of the two. I can't remember why I didn't do that initially.

[voxpelli]

There is one major difference between the current implementation in type-fest and the implementation in the camelcase module:

type-fest/test-d/camel-case.ts

Lines 9 to 10 in e5732ab

	const camelFromPascal: CamelCase<'FooBar'> = 'fooBar';
	expectType<'fooBar'>(camelFromPascal);

type-fest supports conversion from pascal case to camel case.

One could argue that this should be dropped because one can just as well use the TS Uncapitalize<> helper instead, but it would still require a change in logic here.

Also, as a reference, CamelCase<'ID'> was added in: #220

And support for conversion from screaming kebab/snake/space cases was added in: #234