When I lint my code with common Go linters like shadow, then I expect third party code in vendor/ to not be scanned. As I do not control this code.
$ go vet -vettool="$(which shadow)" ./...
# gitlab.com/gomidi/midi/v2/drivers/rtmididrv/imported/rtmidi
In file included from rtmidi_stub.cpp:4:
./cpp/RtMidi.cpp:1555:15: warning: variable length arrays in C++ are a Clang extension [-Wvla-cxx-extension]
./cpp/RtMidi.cpp:1555:15: note: read of non-const variable 'bufsize' is not allowed in a constant expression
./cpp/RtMidi.cpp:1554:13: note: declared here
Using Go 1.24 with go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow@latest
Dozens of workarounds have been proposed on Stack Overflow, but they depend on GNU/BSD extensions to findutils. This breaks many Windows environments, many *nix environments, and other operating systems besides. Yet others solutions depend on gometalinter (bloatware). All of these involve piping to child processes and all the complexity that comes with (good luck portably implementing set -o pipefail on current systems).
Seeking a pure Go solution, ideally go vet simply does this by default.
Frankly, shadow and other x tools should inherently know how to properly recurse over large Go project directories, automatically ignoring any vendor directories. It’s a pain to wire up the which portion in a portable manner without something like mage-extras. I personally use mage[-extras], but many devs will want to use make or yet other build tools.
Update: Even stock vet without shadow experiences the same problem of generating warnings for native C/C++ code in vendor directories.