<p dir="auto"><a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="102609240" data-permission-text="Title is private" data-url="https://github.com/golang/go/issues/12278" data-hovercard-type="issue" data-hovercard-url="/golang/go/issues/12278/hovercard" href="https://github.com/golang/go/issues/12278">#12278</a> was originally about this, but was changed to be about go/build.</p>
<p dir="auto">go/build and x/tools/go/loader now know about vendor directories, but there is more work to do to make goimports add the correct paths.</p>
<p dir="auto">When working on <code class="notranslate">$GOPATH/src/a</code> that vendors <code class="notranslate">b</code>, instead of adding the (disallowed) import <code class="notranslate">"a/vendor/b"</code>, goimports should add <code class="notranslate">"b"</code>.</p>
<p dir="auto">If someone is working in a tree where they have gone to the trouble to vendor a package, as long as the vendored copy is visible (not blocked by internal) we should make sure the vendored copy is always preferred. Otherwise goimports may hurt more than it helps in these situations.</p>
<p dir="auto">Once there is a standard config file explaining what has been vendored, goimports could just read it and when it wants to use X but there's a vendored copy visible, use the vendored copy instead.</p>
<p dir="auto">This came up in a private discussion with an external project about vendoring.</p>