THthunderbong·Aug 29, 2022Submission
Viper: Go Configuration with Fangs
3 points · Open discussionspf13
viper
Go2017–2026
spf13 / viper
viper
Go configuration with fangs
18Distinct people
19Mentions
0Explicit recommenders
30.5KGitHub stars
What to know before exploring
What it is
Go configuration with fangs
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- spf13/cobra · linked in 3 of the same discussions
- spf13/pflag · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:59:22 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year19 dated mentions
Observed mentions: 2017-09-07 20:00:36 UTC to 2026-07-16 15:44:45 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
7 sourcesI contribute to open source projects as well - in various capacities - and it's fine for a maintainer of a huge project to use that wording.
He pushed hugo and viper in 2013-2014: https://github.com/gohugoio/hugo/commits/v0.7, viper: https://github.com/spf13/viper/commit/98be071
Steve is a very accomplished programmer, with what hugo / viper became in the go ecosystem by itself. In my view, the projects also jumpstarted a lot of new users who were trying out golang who weren't sold on it yet. I didn't really notice his leadership or advisory roles until now, that's just icing on the cake.
Thanks for your contributions, Steve!
Edit: If it's really big ecosystem, _indirect_ contributions also matter. e.g. in python, even if you're not writing CPython patches or PEPs, community based projects do a lot to shape best practices and even bubble
Read the rest
up into standard library.
Use viper with care. It has some dangerous fundamental flaws [1]. We got bitten hard, submitted a PR [2] and followed up for a year and a half to no avail, before I went ahead and reinvented the wheel and wrote koanf (plug), specifically to avoid viper's flaws.
Most importantly:
- Breaks JSON, YAML, TOML etc. language specs by forcibly lowercasing all keys internally. Dangerous because it can silently merge differently cased config keys into lowercase.
- Hard codes big unnecessary dependencies into the core, significantly bloating build sizes. No separation or abstraction.
[1] https://github.com/spf13/viper/pull/635
[2] https://github.com/knadh/koanf#alternative-to-viper
In Viper – Go Configuration with Fangshttps://github.com/spf13/viper/blob/master/go.mod
16 direct dependencies, 39 transitive dependencies, and nearly 7000 lines of code -- for a package that handles flags and config files. I can't help feeling that frameworks like this are a little overwrought. It's the sort of project that succeeds because thousands of people just need something that works, right away, so they search for "golang config" and click the top result. Whereas if you can afford to slow down a little, you might find that the stdlib (with a bit of glue) is a perfectly serviceable option for the majority of apps.
In Viper – Go Configuration with FangsViper – Go Configuration with Fangs
10 points · Open discussionThe dependency that was dropped has many dependencies that would get added to your project.
https://github.com/spf13/viper/blob/master/go.mod
In Coral, a Cobra fork with nearly all its features, but only 4 dependencies> From a security stand point, reduced application code decreases risk. It was service discovery code he removed, what if it reached out to discover services on application start up, that's a potential attack vector.
Agreed. I've see a similar pattern with certain open source libraries.
The first example I think of is the spf13/viper [1] library, used to load configuration into go applications. Viper is equipped with code for reading config from various file formats, environment variables, as well as remote config sources such as etcd, consul. If you introduce the viper library as a dependency of your application to merely read config from environment variables and YAML files in the local filesystem, then your go application suddenly gains a bunch of transitive dependencies on modules related to remote config loading for various species
Read the rest
of remote config provider. It's not uncommon for these kind of remote config loading dependencies to have security vulnerabilities.
As well as the potential increased attack surface if a bunch of unnecessary code to load application configuration from all manner of remote config providers ends up in your application binary [2], if you work in an environment that monitors for vulnerabilities in open source dependencies, if you depend on an open source library that drags in dozens of transitive dependencies you don't really need, it adds a fair bit of additional overhead re: detecting, investigating and patching the potential vulnerabilities.
I guess there's arguably a "Hickean" simple-vs-easy tradeoff in how such libraries are designed. The "easy" design, that makes it quick for developers to get started and achieve immediate success with a config loading library, is to include code to load config from all popular supported config sources into the default configuration of the library, reducing the amount of steps a new user has to do to get the library to work for their use case. A less easy but arguably "simpler" design might be to only include a common config-provider interface in the core module and push all config-provider-specific client/adaptor code into separate modules, and force the user to think about which config sources they want to read from and then manually add and integrate the dependencies for the corresponding modules that contain the additional code they want.
edit: there has indeed been some discussion about the proliferation of dependencies, and what to do about them, in viper's issue tracker [3] [4]
[1] https://github.com/spf13/viper
[2] this may or may not actually happen, depending on which function calls you actually use and what the compiler figures out. If your application doesn't call any remote-config-provider library functions then you shouldn't expect to find any in your resulting application binary, even if the dependency is there at the coarser-grain module dependency level
[3] https://github.com/spf13/viper/issues/887
[4] https://github.com/spf13/viper/issues/707