4 ms·

My main gripe with it is the missing separation between test and prod dependencies. Let's say you work on program A, which depends on library B. Library B uses

My main gripe with it is the missing separation between test and prod dependencies. Let's say you work on program A, which depends on library B. Library B uses library C as a test dependency. It shouldn't have any effect on A whatsoever and should not even be downloaded. Yet it is. Apart from the obvious bandwidth and storage space wasted, this is also a problem when compiling an SBOM (Software Bill of Materials) and when scanning for vulnerable dependencies. There is simply no way to tell if your Go binary is vulnerable simply by looking at the go.mod/go.sum file, you have to build and analyze the binary and hope that everything went well. Same for compiling NOTICE files for license compliance. (wink wink Apache license) This isn't an unknown or unsolved problem either, Maven solved this ages ago. There are also some minor nitpicks, such as their absolute requirement to do path-based semantic versioning from v2, but not from v1 or v0. If you change anything, but absolutely anything that's publicly visible, you must increase the minor version of the library you are publishing or you will have a really bad time. If you want to publish both a library and an application, you have to either version them with ridiculous version numbers, or you have to split the two.

Thaxll 3y ago
What's the problem that your tests depends on lib C, if it's using it it makes sense that the main program depends on it. Go test are part of the main program, if you want them separated then create another module that import a and c for testing.
- janosdebugs 3y ago
  It's not _my_ tests that depend on C, but B's tests. I don't maintain B, nor do I care for its tests. They shouldn't be in my dependency tree at all. This is a problem because every time C has a vulnerability, you get a deluge of vulnerability scanner alerts or Dependabot pull requests to update it, even though your application has nothing to do with C. If anyone has a solution for this, I'd really love to hear it because it consumes a silly amount of time to deal with bogus vulnerability alerts.

Thaxll 3y ago

What's the problem that your tests depends on lib C, if it's using it it makes sense that the main program depends on it. Go test are part of the main program, if you want them separated then create another module that import a and c for testing.

janosdebugs 3y ago
It's not _my_ tests that depend on C, but B's tests. I don't maintain B, nor do I care for its tests. They shouldn't be in my dependency tree at all. This is a problem because every time C has a vulnerability, you get a deluge of vulnerability scanner alerts or Dependabot pull requests to update it, even though your application has nothing to do with C. If anyone has a solution for this, I'd really love to hear it because it consumes a silly amount of time to deal with bogus vulnerability alerts.