There should be some kind of message maybe in the gopls (server) output stating that a message wasn't recorded to PROBLEMS because it is from a file inside a "vendor" folder.

Also, maybe errors should be reported to PROBLEMS if you open code inside a folder which is a subfolder of vendor since you're probably developing in the vendored project itself.

I have resolved this issue, maybe you can try it?

index 8914d0dc..b7213f50 100644
--- a/internal/lsp/cache/load.go
+++ b/internal/lsp/cache/load.go
@@ -440,7 +440,7 @@ func (s *snapshot) setMetadata(ctx context.Context, pkgPath packagePath, pkg *pa
                // The package's files are in this view. It may be a workspace package.
                if strings.Contains(string(uri), "/vendor/") {
                        // Vendored packages are not likely to be interesting to the user.
-                       continue
+                       // continue
                }

                switch {
(END)

golang/tools#278

Thank you for looking into this issue, @Mutated1994. Unfortunately, I think we will have to spend some more time understanding how we can support features in vendored packages without marking them as workspace packages--since we diagnose all packages in the workspace.

Thank you for looking into this issue, @Mutated1994. Unfortunately, I think we will have to spend some more time understanding how we can support features in vendored packages without marking them as workspace packages--since we diagnose all packages in the workspace.

Gotcha!

Thanks @stamblerre for linking me here. In my case, some features are already working inside the vendor directory. I'm able to get references, implementations, definitions for few types. It's just not clear what works and what doesn't.

Noting that I ran into issues because I had created an package internal to my project with a path like <ROOT>/module/vendor/foo. Took me quite a while to figure out why LSP features were not working in files under the /module/vendor/foo/ directory.