Switch from Viper to something else?

[penberg]

We use Viper for really simple local settings file, but the amount of dependencies it pulls is very large:

spf13/viper#707

Let's consider using something else instead of Viper to reduce the number of dependencies.

[avinassh]

I always thought Go only imports the libraries which are used, but looking at the thread it seems it is otherwise. TIL.

Current binary size (plain go build and no optimisations) on my machine is 27 MB. I will check with https://github.com/knadh/koanf and report here.

koanf fits well as a replacement, we need support of both JSON file and env variables. Another alternative is https://github.com/ilyakaznacheev/cleanenv but I don't have any preference of one over another.

[avinassh]

I removed viper entirely, it didn't make significant difference in the binary size (26MB).

Go has tooling to analyse the binary size, here are the top five external dependencies by size:

$ go tool nm -sort size -size turso
...
github.com/rivo/uniseg
github.com/libsql/sqlite-antlr4-parser/sqliteparser
github.com/chiselstrike/iku-turso-cli/internal/tetris
github.com/gdamore/tcell
github.com/mattn/go-sqlite3

I used a visualiser and here is the svg:

viz

(The entire reported size by go tool is being shown as ~20MB, I am guessing it strips off the debug symbols)

So, one way to reduce the size would be to strip debug and symbol table info:

go build -ldflags="-s -w"

This reduces the size to 20MB from 27MB and this does not affect stack trace / panic info.

I found one more trick, by using upx the size now reduced to tiny 5 MB. One downside people mentioned that it can affect startup time since all of it is decompressed at the time of executing, but I did not notice any difference.

(all of this run on my intel mac running monterey, with go 1.20)