Snake case underscore before numbers

[ghost]

At the moment, snakeCase doesn't insert an underscore before numbers. I would expect it to do that.

Current behaviour: changeCase.snakeCase("pricePer100Km") returns price_per100_km.

Expected behaviour: changeCase.snakeCase("pricePer100Km") returns price_per_100_km.

If this is not a bug, then I would suggest making it an option through a possible argument. Maybe like this:

changeCase.snakeCase("pricePer100Km", {handleNumbers: true}) returns price_per_100_km.

[blakeembrey]

The problem is that Per100 is highly ambiguous. It's not clear those are two different words in camel case. Happy to accept a PR to add the option. For example, there's a similar option to merge numbers in https://github.com/blakeembrey/camel-case.

[jonlambert]

Any chance of this getting merged? I'm looking for a solution which can correctly split apart numbers from camel case strings like this.

[moltar]

FYI lodash's snake case does the right thing with numbers.

[blakeembrey]

The "right thing" can be subjective, e.g. TestV1. Happy to change the default, but it's hard to get consensus and it'll inevitably upset someone. For context, I'm sure this package originally worked the way you suggest but it likely change in response to a bug report.

[aayush123]

@blakeembrey I created a PR with the new option. However, I did have to copy the default Split Regex. Would it be better if we exported the default regex from nocase and extend the array in this package? I believe it would allow better maintainability in future.

[blakeembrey]

Would it be better if we exported the default regex from nocase and extend the array in this package?

Yeah, that makes sense to me. Since it's a pretty global option, do you want to just have it as a configuration for the base no-case package which all other packages can pass along?

[moltar]

FYI lodash's snake case does the right thing with numbers.

The "right thing" can be subjective, e.g. TestV1. Happy to change the default, but it's hard to get consensus and it'll inevitably upset someone. For context, I'm sure this package originally worked the way you suggest but it likely change in response to a bug report.

Just ran into a case where "the right thing" doesn't make sense: hex strings.

I think we should either have a flag or a new function that handles numbers differently, as clearly different use cases call for different handling here.

To be clear, this package handles hex well, by not splitting up numbers. But lodash puts _ before numbers.