Consider updating declared Go version in go.mod

[JackMordaunt]

The go.mod file declares go 1.13 right now. Module graph pruning was added in Go 1.17, meaning that other modules can import your module and only pick up the transitive dependencies that are actually reachable based on how they use your code. Right now, importing websocket means importing, for example, a protobuf package because the declared go version predates go 1.17.

The tidiest dependency graph will come from using go 1.18, as:

The [go.sum file](https://tip.golang.org/ref/mod#go-sum-files) recorded by [go mod tidy](https://tip.golang.org/ref/mod#go-mod-tidy) for a module by default includes checksums needed by the Go version one below the version specified in its [go directive](https://tip.golang.org/ref/mod#go-mod-file-go). So a go 1.17 module includes checksums needed for the full module graph loaded by Go 1.16, but a go 1.18 module will include only the checksums needed for the pruned module graph loaded by Go 1.17. The -compat flag can be used to override the default version (for example, to prune the go.sum file more aggressively in a go 1.17 module).

Go 1.18 is also the oldest Go release still supported by the Go team, so it's a reasonable choice of language version to declare.

[nhooyr]

Interesting, will do.

[joshklop]

While I agree that updating the module version would be beneficial overall, I don't think it will allow other modules to avoid importing packages that are imported by nhooyr.io/websocket.

The way I understand it, module graph pruning optimizes how the go tool builds its internal representation of the dependency tree. This could potentially speed up builds and other operations like go mod tidy for downstream projects, but doesn't affect binary sizes, for example.

[nhooyr]

Done in dev.