Fixed as of CL 239198, though VS Code does not support watching directories outside of the workspace root.

Fixed as of CL 239198, though VS Code does not support watching directories outside of the workspace root.

Is this fixable, otherwise it seems to me that this means extending modules via the filesystem and package main is a better solution than replace and named modules? Not reliable on Windows unfortunately but workable on Unix systems.

I guess the other option is unworkable (putting all projects in one module) as in my experience, a library change might make build errors unhelpful and will be a pain with so many files in scope.

Edit: Actually replaced libs outside vscodes root, seems to work today, if you disable gopls.

Arrgh still has some issues with build tags then.

The title of this issue is a bit misleading--specifically, the issue is that on-disk changes to replaced modules will not be reflected to the editor because of limitations to VS Code's file watching API. gopls should still generally work with replaced modules. @kevlar700: If you are having an issue with the VS Code Go extension, please take a look at the Troubleshooting guide and file a new issue.

If you are having an issue with the VS Code Go extension, please take a look at the Troubleshooting guide and file a new issue.

I think one issue might be that more people are using replace than perhaps should be?

"https://www.mail-archive.com/golang-nuts@googlegroups.com/msg41347.html"

Not sure whether to file an issue about documentation somewhere?

Replace directives should work with gopls, and it's perfectly fine to use them if they fit your use case. In fact, gopls uses a nested module with a replace directive itself. As I mentioned above, if your set-up is causing issues with VS Code Go and gopls, we'll be happy to take a look and investigate the problem.