Hi,
This is absolutely right. The limitation is with golang rather than the gateway, but for a module to be loadable it must have been compiled with the same golang version and the same versions of all of the libraries used. This is why the plugin compiler image is provided.
To get around the go.mod problem I use the plugin compiler to generate it like this:
(Please backup your go.mod and go.sum before doing this if they’re important to you.)
rm go.mod go.sum
docker container run -v `pwd`:/plugin-source -t --workdir /plugin-source --entrypoint go --rm tykio/tyk-plugin-compiler:v5.2.5 mod init myCustomPlugin
Then I can compile the plugin. Since you’re using v5.2.5 it’s possible to get the compiler to run the necessary go mod tidy and go get commands itself like this:
docker container run -v `pwd`:/plugin-source --env GO_TIDY=1 --env GO_GET=1 --rm tykio/tyk-plugin-compiler:v5.2.5 myCustomPlugin $(date +%s%N)
Note the $(date +%s%N) on the end of the compilation command above. This adds a plugin id that is unique to this build of the plugin. Golang requires that plugins have a unique plugin id. Without a unique plugin id you’ll eventually run into the dreaded plugin is already loaged error during plugin development.
Once this is completed you should have a directory that looks like this no matter what OS or local golang version is installed.:
$ ls -l
total 8636
-rw-rw-r-- 1 user group 450 Nov 2 2022 myCustomPlugin.go
-rw-r--r-- 1 user group 31 Apr 2 09:24 go.mod
-rw-r--r-- 1 root root 8826904 Apr 2 09:27 myCustomPlugin_v5.2.5_linux_amd64.so
Cheers,
Pete