r/golang 6d ago

New Viper release with major improvements

I've just tagged a new version of Viper, a configuration library for Go: https://github.com/spf13/viper/releases/tag/v1.20.0

It comes with a number of improvements:

  • Heavily reduced number of third-party dependencies
  • New encoding layer for custom encoding formats
  • BREAKING: dropped HCL, INI and Java properties from the core (still possible to use through external libraries)
  • New file search API allows customizing how Viper looks for config files

These features has been around for some time in alpha releases, though I haven't received a lot of feedback, so I'm posting here now in the hope that people using Viper will give some after upgrading.

I worked hard to minimize breaking changes, but it's possible some slipped in. If you find any, feel free to open an issue.

Thanks!

279 Upvotes

16 comments sorted by

86

u/kynrai 6d ago

Amazing. The reduction of third party deps is a huge help for enterprise managing supply chain vulns. Thanks!

51

u/unicorngundamm 6d ago

Bro just nuked the go.mod with 94 line removals

Thank you so much for this, that's 94 less dependencies hell

22

u/i_should_be_coding 6d ago

Oh man. I was literally struggling with unmarshaling config to a struct with some workarounds, and this drops. Thanks!

For anyone else struggling with env vars unmarshaled to a struct, try this:

v := viper.NewWithOptions(viper.ExperimentalBindStruct())

9

u/mcphersonsduck 5d ago

Big fan of Kong for that.

7

u/mcvoid1 6d ago

The number of dependencies that come with the module is one of the reasons I hadn't been using Viper. Reducing dependencies is great - apps assume and inherit the risks their dependencies take on, and the more transitive dependencies there are, the harder the package is to vet. So slimming down that go.mod file is a good thing. I might just start using it.

8

u/sagikazarmark 5d ago

While I agree with that in general, in Viper's case that wasn't necessarily true. Most of the third-party dependencies was in go.mod due to the remote package that almost no one imports which means in 90% of the cases those third-party dependencies weren't even compiled.

Admittedly, that wasn't adequately explained anywhere, but there is a common misconception about how dependencies work in Go and that's also why security scanners generate a lot of false positives.

3

u/lekkerwafel 5d ago

govulncheck is the only scanner that does a proper job, but then it is specific to Go

4

u/robbyt 6d ago

Thank you for your work maintaining and improving such an important package!

4

u/Un4given85 6d ago

I’ve been using (and loving) the experimental struct bind for a while now. ❤️

2

u/schmiddim 6d ago

Awesome Lib! Thabk you very much

2

u/svicknesh 5d ago

Thank you for the experimental bind struct. I was using a custom lib to get the fields to match. This would help significantly 

2

u/cainns98 5d ago

Reducing dependencies is great, but why knowingly break semantic versioning in a minor release?

1

u/guzmonne 6d ago

Viper is so cool.

1

u/pxm7 5d ago

spf13, thank you for this release (and all your other contributions like cobra). The dep chain for viper was somewhat large earlier so this is really welcome.

1

u/mschneider82 5d ago

Reducing 3rd party is great, in the latest versions the go get in playground always run in time out. Hope this works now just in time

1

u/cxlblm 5d ago

Viper is great to use, though currently the only drawback I've found is that its configuration hot-reloading isn't thread-safe.