Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set CGO_CFLAGS=-g -O2
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\~1\AppData\Local\Temp\go-build3923578036=/tmp/go-build -gno-record-gcc-switches
What did you do?
Used //go:embed <dir> to recursively embed static website assets into an embed.FS variable, and then ran go install <repo> to install the binary into gobin.
What did you expect to see?
All assets embedded into the embed.FS variable in the final binary in gobin.
What did you see instead?
Only some assets were embedded in the embed.FS variable in the final binary in gobin.
The problem comes from having folders named vendor within the directory that gets embedded.
If you create a project that embeds a directory, for example //go:embed static, which includes some sub-directory named vendor, for example static/vendor/style.css, then the embed behaviour is different depending on how you install the project into gobin.
If you have the entire project source locally and you run go install within the project then the vendor directory is correctly included and embedded into the final binary.
If you push the project to somewhere like GitHub and then try to install via go install <repo> or go get <repo>, then all files are correctly embedded according to the documentation except for the entire vendor folder, which is ignored. You can work around this by setting GO111MODULE=auto. If this is set then the vendor directory is no longer ignored and is correctly embedded in the final binary.
I believe this is just an unintended side-effect of go get/go install and how they deal with vendored dependencies. If it is actually intended then it at the very least needs to be documented and made consistent across the different methods of installation.
The text was updated successfully, but these errors were encountered:
Patterns must not match files outside the package's module, such as ‘.git/*’ or symbolic links. Matches for empty directories are ignored. After that, each pattern in a //go:embed line must match at least one file or non-empty directory.
Perhaps we are also missing a check to cause the build to error out if the pattern does match files in the vendor directory? That should be an explicit error — it shouldn't implicitly drop files that match, although things get a bit tricky when we consider glob patterns (which should just stop at module boundaries without erroring out).