deno_std
deno_std copied to clipboard
denoland
add string case utilities
Today, there are no string case utilities in the std lib, but one need only look around to npm briefly to see that there is a healthy appetite for shared modules to handle the complexities of converting strings between different cases:
- case (~500k weekly downloads)
- case-anything (~90k weekly downloads)
- pascalccase (~16M weekly downloads)
- camel-case (~16M weekly downloads)
- lodash.camelcase (~8M weekly downloads)
- lodash.deburr (~1M weekly downloads)
Note that
lodashhas lots of string utilities that would be excellent to have "official" std lib support for
Some of these examples are "general" string case conversion modules, and others are for a specific case conversion (and in the case of lodash.deburr it is a module for removing diacritical marks from Latin character sets to make the case conversions more reliable).
I myself incorporate case via npm: specifiers in my largest Deno project because having access to a well tested and well implemented module to convert a string to:
- upper (UPPER CASE)
- lower (lower case)
- title (Title Case)
- snake (snake_case)
- pascal (PascalCase)
- camel (camelCase)
- kebab (kebab-case)
- constant (CONSTANT_CASE)
which handles the edge cases around diacritical marks, weird spacing, etc is very helpful.
I saw https://github.com/denoland/deno_std/pull/3124 which attempts to establish a strings module category for the std lib, so these are related requests, though neither depends on the other.
Thank you for considering, and thank you for Deno (and the excellent std lib)!
@andrewbrey do you see this being part of an existing module or something new?
E: I think this could easily be added to fmt.
As per the discussion in #3124, a strings module might be unneeded. I do think a fmt/case.ts file would be very useful. I'd be interested in coding this.
do you see this being part of an existing module or something new?
That's not something I have an opinion on - I mentioned the related PR because it's attempting to establish a strings top-level folder in the stdlib, where I could see the outcome of this feature request living, but I could also see this feature request tucking neatly within the existing fmt top-level folder as well.
This has been mostly completed in #4082. Functions for more casing will be handled in new issues. Thank you for the suggestions and contributions.
Was just reaching for a CONSTANT_CASE function and realized it doesn't exist. Needed to dynamically generate an env variable name. I think this should be added.
Is CONSTANT_CASE the common name? I found one usage in https://www.npmjs.com/package/change-case, but wikipedia and MDN seem referencing it is SCREAMING_SNAKE_CASE https://en.wikipedia.org/wiki/Snake_case https://developer.mozilla.org/en-US/docs/Glossary/Snake_case
Is CONSTANT_CASE the common name? I found one usage in https://www.npmjs.com/package/change-case, but wikipedia and MDN seem referencing it is SCREAMING_SNAKE_CASE https://en.wikipedia.org/wiki/Snake_case https://developer.mozilla.org/en-US/docs/Glossary/Snake_case
I think CONSTANT is the most common and understandable for devs. However IMHO no problem to export a symbol with more than one name when different names exist. But I think if you need one, constantCase is more common than SCREAMING_SNAKE_CASE. CAPITAL_SNAKE_CASE is maybe a more literal name, regardless of what's common.
Was just reaching for a CONSTANT_CASE function and realized it doesn't exist. Needed to dynamically generate an env variable name. I think this should be added.
What is your use case for a dynamic env variable? This sounds like a similar thing situation to wanting dynamic variable names.
Was just reaching for a CONSTANT_CASE function and realized it doesn't exist. Needed to dynamically generate an env variable name. I think this should be added.
What is your use case for a dynamic env variable? This sounds like a similar thing situation to wanting dynamic variable names.
the scenario is using a convention for env var names.
Good idea. A PR would be welcome. CONSTANT_CASE makes sense to me, and I'd expect most devs to understand it. Also, it's shorter. As long as the name makes sense 🤷🏾♂️