Thanks for the reply, I have a couple of questions

, we should probably use ConfigFieldMapping directly instead of a general function (in your specific case, it would be ConfigFieldMapping(ScreamingSnakeCase, KebabCase));

I just had a look at ConfigFieldMapping and from what I can tell reading the documentation it seems its only meant to apply to case class fields and not actual values (i.e. the rhs of the =), i.e.

myField=something

vs

my-field=something

Wouldn't it be confusing to use a ConfigFieldMapping for both keys and values? In my case I want the transformation to only apply to values and not keys/fields.

BasicReaders should include only ready-to-use reader instances, not instances that need to be "configured". We have a package pureconfig.configurable to hold readers that need to be constructed explicitly. Can you please move your baseJavaEnumReader there, renaming it to something like javaEnumReaderWithMapping

Agreed however should we still have a main implicit val chronoUnitReader: ConfigReader[ChronoUnit] in JavaTimeReaders? I believe there is a difference between configurable readers for things like date time formatters (where there are legitimately different unique formats for date time) and something like ChronoUnit where you have different cases for the same thing (i.e. half-days vs HALF_DAYS vs half_days). Wouldn't having a single kebab case (as you suggested) reader for ChronoUnit be more preferable since any other kind of configuration would be simply be non standard for typesafe config?

Wouldn't it be confusing to use a ConfigFieldMapping for both keys and values? In my case I want the transformation to only apply to values and not keys/fields.

I'm afraid the documentation (and the class name itself) are a bit misleading. ConfigFieldMapping is used generally as a way to map between naming conventions, regardless of whether they're applied in keys or values. For example, besides case class field mapping, it's also used to choose the values for the disambiguation type field in sealed families (e.g. type = blue-car to select a BlueCar subclass). It's ok to use it for this use case 👍

Agreed however should we still have a main implicit val chronoUnitReader: ConfigReader[ChronoUnit] in JavaTimeReaders?

Yes, chronoUnitReader should remain in JavaTimeReaders just like you did, and its implementation should call our new configurable reader - I see no problem with a "non-configurable" reader being a particular instance of a configurable one (particularly one so general like a reader for all Java enums).

Thanks for the responses, I will work on the PR tomorrow!

@ruippeixotog I believe I have done the changes (along with re basing on master), let me know if anything else needs to be done.

@ruippeixotog I have resolved all of your remarks, I also ended up adding a round trip test for ChronoUnit

@ruippeixotog Sorry for disturbing but would it be possible to make a release of pureconfig with this change in there?

Hi @mdedetrich, I'll do it next week 👍

Awesome, thank you!