Repository navigation
Consider using more normal casing rules #56
Description
Since I'm filing issues with suggested breaking changes anyway (#55), I thought I'd file this one as well...
It's very confusing for me that this library doesn't follow the usual camelcasing rules of uppercasing every word after the first. (Seen e.g. in standard APIs like Uint16Array.) Instead, it seems to lowercase words if they follow a number. This has led to a number of runtime failures for me and my LLMs as we try to write code against the library.
It would be nice if this library updated its method names, e.g. fromBase32hex -> fromBase32Hex, windows1252fromString -> windows1252FromString, etc.
Activity
ChALkeR commentedon Jan 29, 2026
This can be done in a non-breaking way (aliases + typedoc-deprecations), but there was some logic behind that, which I need to recheck
ChALkeR commentedon Jan 29, 2026
All of the methods follow the same pattern: letters directly after digits are not capitalized.
There are a lot of digits in the middle of function names, and capitalizing letters after those hurts readability for humans.
Even in the examples above: in
fromBase32Hex/windows1252FromStringthe first letter after digits reads as a contiuation of the digits because of the same height and being valid hex in some cases.Case switching in camelcasing is needed for parts separation, and a lowercase letter after digits better visually separates the part from digits than an uppercase letter.
LLMs should be using .d.ts?
domenic commentedon Jan 29, 2026
I don't think that's true... I think breaking from convention hurts readability more. It certainly makes me visually stumble as I end up having to internalize the rules which are unique to this library over the ones that the rest of the JS ecosystem uses.
A lot of the times they just assume that if one method exists, the others must as well. They'll figure it out and go consult the
.d.tsafter they get errors, but it's extra tokens wasted.ChALkeR commentedon Jan 31, 2026
I still don't buy the llms argument, it would be void anyway in less than several months
Throwing off humans is more significant, and with introduction of
isomorphic*the casing would indeed look inconsistent (as there are no numbers) and it'll haveFromStringandToStringper the current naming schemeI need to think about it
Affected methods:
ChALkeR commentedon Feb 1, 2026
Some of them seem strange and more confusing when capitalizing the other way:
The encoding is
"base64url", its camelcase should beBase64url, notBase64UrlAlso ref: sindresorhus/camelcase#77, sindresorhus/camelcase#112, https://github.com/sindresorhus/camelcase#capitalizeafternumber
Same for
base32hex, it's the encoding name,32is not a divisor, the encoding name shouldn't be capitalized toBase32Hex. Likebase64urlshould not be capitalized toBase64Url(Urlcasing itself is very confusing).i.e.
fromBase32hexisfrom_base32hex, notfrom_base32_hex@domenic wdyt on that ^
So what remains are only:
domenic commentedon Feb 2, 2026
I just disagree with this assessment. The examples you list all look natural, because the follow the casing rules that I've used in JavaScript for the last ~15 years.
I agree the rules for how to use camel-casing when you have a predefined term that is often written using another case can be tricky. (E.g.,
base64urloften written using squishedtogethercase.) I would still mentally stumble as I'd have to combine together my usual JavaScript instincts of camel casing with this domain-specific choice to use squishedtogethercase. So my preference would be to stick to the JavaScript standard.