Sounds more like a vscode issue, doesn't it?

that was only an example, but any IDE will behave the same , the main problem is the git workflow though.
The general rule is to never manually touch anything in the vendored folder, so the only way to do this and still make changes to a package would be like I suggested.

@cznic what is your git workflow when you make changes to a vendored package? I am happy to try any suggestions.

Never ever used vendoring. I have no need for it. Seems like with vgo the support for vendoring may get dropped anyway.

without vendoring ,what happens if the source disappears or changes names?

Nothing. It's on all my machines and in our Gitlab. But generally I try to avoid importing packages that may disappear or break.

vendoring isn't going away as an option most likely: https://groups.google.com/forum/#!topic/golang-dev/FTMScX1fsYk

Are you familiar with the go.mod "replace" directive?
https://research.swtch.com/vgo-tour (under Replacing)

@kardianos rock star!
it seems to address exactly what I am describing. I will try it shortly

@kardianos Haven't yet read the vgo series except for part 1, unfortunately. But I thought I saw rsc expressed the intent to remove vendoring somewhere (reddit? ML discussion)? Not sure IIRC, though.

No difference for me anyway. Haven't used it before and I don't think that's going to change. I still consider vendoring a mistake.

Replace is definitely what you are looking for, not modifying vendored copies directly (at least not if you want to preserve the changes; that might be fine for debugging maybe).