go.mod: Do not remove other dependencies

[mdreizin]

If Dependabot updates ie. github.com/golang/protobuf from 1.4.3 to 1.5.1 and the repo contains some auto-generated code or unused ones then Dependabot will remove all dependencies.

Package manager/ecosystem

go:modules

Manifest contents prior to update

module github.com/my-org/my-repo

go 1.15

require (
	github.com/golang/protobuf v1.4.3
	github.com/grpc-ecosystem/grpc-gateway/v2 v2.2.0
	google.golang.org/genproto v0.0.0-20210207032614-bba0dbe2a9ea
	google.golang.org/grpc v1.36.0
	google.golang.org/protobuf v1.25.0
)

Updated dependency

-module github.com/my-org/my-repo
-
-go 1.15
-
-require (
-	github.com/golang/protobuf v1.4.3
-	github.com/grpc-ecosystem/grpc-gateway/v2 v2.2.0
-	google.golang.org/genproto v0.0.0-20210207032614-bba0dbe2a9ea
-	google.golang.org/grpc v1.36.0
-	google.golang.org/protobuf v1.25.0
-)

What you expected to see, versus what you actually saw

It would be nice if Dependabot updates only actual dependency and do not remove other ones.

It is easy to fix by telling Dependabot to create a temporary file ie. dependabot.go and copy all deps from original go.mod to dependabot.go:

// +build dependabot

package tools

import (
	_ "github.com/golang/protobuf"
	_ "github.com/grpc-ecosystem/grpc-gateway/v2"
	_ "google.golang.org/genproto"
	_ "google.golang.org/grpc"
	_ "google.golang.org/protobuf"
)

and after that run update and create a new diffs for go.mod and go.sum.

Images of the diff or a link to the PR, issue or logs

[jurre]

Thanks @mdreizin, I guess this happens because we run go mod tidy after the update.

We actually already create such a file if no .go file is present in the root. We could always do that, but the downside is that if you do normally run go mod tidy, we no longer clean up dependencies that are unused after the update.

I think if you commit the file you mention to the repo, that would also work. Another option would be to make go mod tidy optional, but it seems like a good default. wdyt?

[mdreizin]

@jurre Thank you for the instant reply. I am going to use that temporary workaround, but it would be nice to have that approach out of the box.

[jeffwidman]

Please keep the current default of running go mod tidy... it keeps my life sane. I can't really envision a scenario where it wouldn't make sense to do that. Probably if someone is having an issue with the output, they should really be filing an issue against go mod tidy behavior and not against dependabot.

[jeffwidman]

Closing, as I don't see us moving away from executing go mod tidy, . Beyond providing sane defaults, it also does some error checking that lets us know if things might be in a broken state as we prepare the upgrade.

As noted in #3617 (comment), a potential workaround here is comitting a *.go file that imports the libs you want to keep in the go.mod file.