Open phm07 opened 2 months ago
👋 Thanks for contributing to Viper! You are awesome! 🎉
A maintainer will take a look at your pull request shortly. 👀
In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues.
⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9
📣 If you've already given us your feedback, you can still help by spreading the news, either by sharing the above link or telling people about this on Twitter:
https://twitter.com/sagikazarmark/status/1306904078967074816
Thank you! ❤️
This PR proposes a new function
viper.Origin
that allows finding the origin of a configuration value. It might be used for following use cases:viper.Origin(key) < viper.ValueOriginDefault
)The implementation is largely based on
(*Viper).find
, but instead of returning the option values, it returns aviper.ValueOrigin
based on the current code path.Alternatively, you could also return a
ValueOrigin
from(*Viper).find
and then expose that throughviper.Origin
. This way there would be less code duplication. Let me know if you prefer this approach.What still needs to be done/discussed:
ValueOrigin
typeviper.ValueOriginOverride
are quite long.int
orstring
as underlying type?string
allows for easy human-readable output,int
allows for comparisons inside of the hierarchy (see above). Maybe add(ValueOrigin).String()
?int
is used, the order of the values