https://kotlinlang.org logo
#hoplite
Title
# hoplite
r

rocketraman

03/18/2024, 12:15 PM
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.
s

sam

03/18/2024, 12:35 PM
I think it would be trivial to add what you want with the prefix on load or throw.
👍 1
I want to get 2.8.0 and clear the issues queue in the coming days anyway.
r

rocketraman

03/28/2024, 6:40 PM
@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.
2 Views