Is there any chance <https://github.com/sksamuel/h...

# hoplite

[rocketraman]

Is there any chance https://github.com/sksamuel/hoplite/issues/386 would see any love in the near future? I would like to transition to hoplite from my forked version of cfg4k (https://github.com/rocketraman/cfg4k), but that issue is a blocker.

[sam]

I think it would be trivial to add what you want with the prefix on load or throw.

[sam]

I want to get 2.8.0 and clear the issues queue in the coming days anyway.

[rocketraman]

@sam I've taken a shot at updating Hoplite with prefix support: https://github.com/sksamuel/hoplite/pull/412. There is more to do on this PR (like tests), but I wanted to get some early feedback from you on this general approach.

After that, I'd also like to implement support for https://github.com/sksamuel/hoplite/issues/410 but based on what I see so far I the problem there is that when sources are merged the node path values have to match exactly otherwise the cascader doesn't work properly.

At the moment the ParameterMapper transforms data class params to various values that are looked up in the node tree, but I'm wondering if many of the `ParameterMapper`'s could actually be turned into `NodeNormalizer`'s that instead operate on the node tree to normalize the paths.

This would allow different sources to use different idiomatic naming but all will get merged correctly. For example:

foo.conf containing the hocon standard approach of abc.foo-bar and an env var ABC_FOOBAR would both get mapped to data class Foo { val fooBar: String }.

You can see an early implementation of the NodeNormalizer that operates only on prefixes here, but we could move a lot of ParameterMapper logic to `NodeNormalizer`s as well: https://github.com/rocketraman/hoplite/commit/6ebe5335b9574c973bd675dcc6fdc2caf33ab1cc

Would love your thoughts.