1

I understand that it is the expected behavior of go mod tidy to prune dependencies tree by removing the unnecessary ones, but part of my CI uses go-swagger to generate swagger JSON files. So, in the end. go mod tidy will remove the go-swagger packages from go.mod file because they're listed as //indirect (they're not used directly from the source code). Is there a workaround?

Here's my go.mod file:

...
require (
    github.com/go-openapi/errors v0.20.0 // indirect
    github.com/go-openapi/validate v0.20.2 // indirect
    github.com/go-swagger/go-swagger v0.26.1 // indirect
    github.com/gorilla/mux v1.8.0
    github.com/mailru/easyjson v0.7.7 // indirect
    github.com/spf13/afero v1.5.1 // indirect
    golang.org/x/mod v0.4.1 // indirect
    golang.org/x/net v0.0.0-20210220033124-5f55cee0dc0d // indirect
    golang.org/x/sys v0.0.0-20210220050731-9a76102bfb43 // indirect
    golang.org/x/tools v0.1.0 // indirect
)

After I run go mod tidy, only this one remains:

    github.com/gorilla/mux v1.8.0

However, I have the following target on my Makefile that runs on production:

$ swagger generate spec -o ./internal/ui/swagger.json

I kind of wanted to avoid calling explictly go get on go-swagger globally after running go tidy. Do you guys have any suggestion on how to workaround this?

phramos07
  • 136
  • 1
  • 8

3 Answers3

4

I suspect one workaround would be to:

  • import explicitly in one of your project source .go file the package github.com/go-swagger/go-swagger/scan
  • define a dummy variable
    var _ = scan.Parse
    

That way, your sources would directly "use" github.com/go-swagger/go-swagger, which would no longer pruned by go mod tidy.

I would do that in a go file named externalTools.go, just to remember why this fake import is needed.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Would this not then bloat the final executable by linking all the swagger libs as well? – Ed Randall Feb 12 '22 at 15:02
  • 1
    @EdRandall I suppose though. https://github.com/samlitowitz/goimportcycle, https://github.com/becheran/depgraph and https://github.com/nikolaydubina/go-binsize-treemap would be able to visualize any bloat. https://github.com/cugu/gocap would qualify their security issue. (That or nancy: https://jcdan3.medium.com/scanning-go-dependencies-for-vulnerabilities-b82db3d56b27) – VonC Feb 12 '22 at 20:16
1

Use go install to install swagger without affecting go.mod.

In your Makefile have a separate target that installs the swagger deps then runs it. Ours is arranged along these lines:

ROOT := $(PWD)
DIST := ${ROOT}/dist

# Could be /go or ${HOME}/go depending on build environment
export GOPATH := ${ROOT}/go

.PHONY: swagger

all: $(DIST)/app swagger

swagger: $(GOPATH)
    go install -v github.com/go-swagger/go-swagger/cmd/swagger@latest
    $(GOPATH)/bin/swagger version
    $(GOPATH)/bin/swagger generate spec -o ./swagger-ui/swagger.json -m

$(DIST)/app: $(DIST) $(GOPATH)
    go build -v -o $(DIST)/app ./cmd/...

$(DIST):
    mkdir -p $(DIST)

$(GOPATH):
    mkdir -p $(GOPATH)
Ed Randall
  • 6,887
  • 2
  • 50
  • 45
0

What about using this commands?

go mod tidy --> removes dependencies from go.mod 
go mod vendor --> removes libraries from vendor

This will remove all unused libraries

Raul Lucaciu
  • 132
  • 7