`go get github.com/golang-jwt/jwt/v4` with `GO111MODULE=off`

[lahirumaramba]

Hey folks,

We use golang-jwt/jwt as a dependency in firebase.google.com/go and we have set up CIs to test both module and GOPATH builds. Lately, we have noticed that the GOPATH builds are failing on github.com/golang-jwt/jwt/v4 with the following error:

github.com/MicahParks/keyfunc (download)
github.com/golang-jwt/jwt (download)
cannot find package "github.com/golang-jwt/jwt/v4" in any of:
	/opt/hostedtoolcache/go/1.17.13/x64/src/github.com/golang-jwt/jwt/v4 (from $GOROOT)
	/home/runner/work/firebase-admin-go/firebase-admin-go/go/src/github.com/golang-jwt/jwt/v4 (from $GOPATH)

I am guessing this is probably because get github.com/golang-jwt/jwt downloads v3 but the code depends on v4, but I thought I should reach out because the GOPATH CI started failing recently without any changes from our end.

You can try the following to reproduce the issue:

export GO111MODULE=off

go get -u github.com/golang-jwt/jwt/v4

Error:

cannot find package "github.com/golang-jwt/jwt/v4" in any of:
	/usr/local/go/src/github.com/golang-jwt/jwt/v4 (from $GOROOT)
	/Users/foo/go/src/github.com/golang-jwt/jwt/v4 (from $GOPATH)

Is this WAI? If not, any thoughts on how we could fix the CIs to use golang-jwt/jwt/v4 in GOPATH builds? Thanks!

[oxisto]

Hmm I am not an export on non-module builds so I am also not quite sure what is happening there. Are you depending on github.com/golang-jwt/jwt or github.com/golang-jwt/jwt/v4? Because github.com/MicahParks/keyfunc definitely depends on v4. Why v4 is not working with GO111MODULE=off is beyond me. We did bump the minimum version to Go 1.16, but I though that 1.16 is still supporting GO111MODULE=off (according to https://go.dev/blog/go116-module-changes).

Please be aware that we are bumping the Go version to 1.18 in v5, so at some point probably non-module build support will fade away.

[lahirumaramba]

Thanks @oxisto. We depend on github.com/golang-jwt/jwt/v4 and use import github.com/golang-jwt/jwt/v4 in the codebase. It is strange because the dependency was working fine on non-module builds until recently.

Thanks for the heads up on v5. Maybe it is time for us to safely drop non-module builds.

[mfridman]

The only thing I can think of that might have changed in the past month is we bumped the module to github.com/golang-jwt/jwt/v5 on main and created a v4 branch which is now pinned to 9358574 and has a v4.5.0 tag.

The minimum go version also got bumped from go1.16 to go1.18.

There must be something throwing off go1.17.x even with modules disabled, but I can't immediately see why changes in this repository would affect something that was previously working.

I could be wrong, but it feels a bit odd consuming a SIV-style import but relying on old GOPATH semantics?

[lahirumaramba]

I could be wrong, but it feels a bit odd consuming a SIV-style import but relying on old GOPATH semantics?

Yeah good point! I am not sure either. If we go back to github.com/golang-jwt/jwt (a non SIV-style import) I think we would have to downgrade github.com/MicahParks/keyfunc to a version that does not depend on v4, which I am a bit hesitant to do as we would want to make sure we are pointing to the latest releases to include all the security fixes.

[oxisto]

I could be wrong, but it feels a bit odd consuming a SIV-style import but relying on old GOPATH semantics?

Yeah good point! I am not sure either. If we go back to github.com/golang-jwt/jwt (a non SIV-style import) I think we would have to downgrade github.com/MicahParks/keyfunc to a version that does not depend on v4, which I am a bit hesitant to do as we would want to make sure we are pointing to the latest releases to include all the security fixes.

Can we consider this issue as closed? I fear that this is actually something in the Go runtime and not specific to our library?

[lahirumaramba]

Yes! We have decided to require module mode to build the current version of the library and drop non-module support. We can close this issue now. Thank you for the help!