Closed aayush123 closed 11 months ago
Do you want to just add an option here: https://github.com/blakeembrey/change-case/blob/c24a0e18044bf77d9e824e93f04f7eb4e2151230/packages/no-case/src/index.ts#L20-L25?
This way would solve the issue for all "cases", since it's more in the interpretation of the string than the formatting side.
If we do that, the regex changes that are done in snake case package would also be moved into no-case so that it can handle numbers there itself. Would that be fine?
@blakeembrey I have moved the separateNumbers
option from snake-case
to no-case
.
Have tested the new option in no-case
, dot-case
, param-case
, pascal-case
& camel-case
. Should I further test all packages for the effects the new option has?
Also, do note that the new test cases will pass only when we use the local no-case
and in turn, local dot-case
etc packages as dependencies. This should be resolved if and when we merge the changes in the repository.
What about appending the two additions you want to the regex list when the option is specified?
@blakeembrey I think appending wouldn't particularly work because we should add the 2 new regexps only when user didn't specify their own splitRegexp
.
So I resorted to creating a new array using the default one and adding the new options to it.
Afterwards, based on whether or not the user provided splitRegexp
and separateNumbers
options, either new or default regexp is used.
Also updated code to de-structure splitRegexp
separately to use let
only for this.
Also, can we get some more test coverage, specifically around the final regex (number then letter) and combinations of things like Foo12019Bar or V1Test.
Added test cases in various packages.
Although, the new option does provide results that may not particularly be useful in camelCase
and PascalCase
(the two that I tested). These two in particular add an underscore before numbers when separateNumbers
is true
. I wonder if it'll be useful in any scenario.
For eg.
pascalCase("Foo12019Bar", { separateNumbers: true }); // "Foo_12019Bar"
pascalCase("aNumber2in", { separateNumbers: true }); // "ANumber_2In"
pascalCase("V1Test", { separateNumbers: true }); // "V_1Test"
Is there still interest in merging this feature? I welcome it.
This PR adds an option to separate numbers when using snake case, resolves #50
Eg:
Earlier,
snakeCase('AddressLine1')
would give'address_line1'
.With new option,
snakeCase('AddressLine1', { separateNumbers: true })
would return'address_line_1'