go.sum is not imports. It's a checksums file, it's used in determining which versions of things to pin to. It doesn't necessarily mean all of those things end up in the final binary. See https://go.dev/ref/mod#go-sum-files. You can run `caddy build-info` to see everything that is a dependency in the build. From my count, a vanilla build of Caddy v2.8.0 has 122 packages as dependencies (many of which are indirect).

(Dividing line count by 2) It looks like we currently rely on about 322 direct or transitive dependencies. It's worth noting many of those are test-only dependencies.

A lot of the /x/ packages are repeated, just different versions; and I believe -- if my understanding is right -- a lot of these are only used for checksum verification, not necessarily a manifest of what is compiled into the binary.

But, the point remains, dependencies can bloat quickly, which is why we went with such a modular architecture for Caddy 2.

that’s nothing compared to the average package-lock.json!

it actually doesn’t seem like that long of a list if you only consider one version per library

This is a bit tangential... I recently noticed that a module that is split into packages that have distinct subsets of dependencies will only add transitives to your own go.mod based on the packages that you actually use.

This tripped me up trying to minimize dependencies for a library by splitting it into a separate repo from the rest of the application, but this is totally unnecessary (and annoying to manage).

Go modules are pretty good.