<p>Since I'm new, I'm sure there is a good reason for this, but this is really ticking me off. Whenever I have an unused import line and save the file, it deletes my import line. I am currently trying things out, commenting code out and back in, and it keeps deleting my imports when I do. (And doesn't have the decency to put it back in when I uncomment the code.)</p>
<p>How do I make it stop deleting my stuff?</p>
<pre><code>package main
import (
"fmt"
"log"
"os"
"github.com/dgryski/go-bitstream"
)
</code></pre>
<p>When I comment out code referring to <code>go-bitstream</code>, that list line disappears when I save. >:(</p>
<p>Maybe this should go into a different subreddit, but the culprits seem to be Go programs being run whenever I save.</p>
<p>Edit: Apparently it will add the correct import as long as I get the package name correct. I was trying to use <code>go-bitstream.NewReader()</code> when <code>bitstream.NewReader()</code> is what I should have been using. Thanks to <a href="/u/TheMerovius" rel="nofollow">/u/TheMerovius</a> and all responders!</p>
<hr/>**评论：**<br/><br/>szabba: <pre><p>It's a compiler error in Go to have an unused import. It's possible the default config of VSCode's Go plugin autoimports the packages that are being used and fixes the import list along with autoformatting the code. If that's the case you should see "fmt" added to the import list after you first use it in an empty program.</p></pre>midnightFreddie: <pre><p>It did indeed add "fmt" when I tried a basic "hello, world" without explicitly importing.</p>
<p>I don't suppose you know offhand if there is a way I could make it recognize where to find <code>go-bitstream</code> automatically?</p></pre>TheMerovius: <pre><p>It actually should be able to figure that out already, if your GOPATH is configured correctly, as long as you a) use the correct package name (for that particular package it's "bitstream", as evident from the header <a href="https://godoc.org/github.com/dgryski/go-bitstream" rel="nofollow">here</a> and b) the way you use it is correct and sufficiently unique (i.e. the "mapping (pkg-name, types you use) → package" must be well-defined).</p>
<p>The idea behind goimports is, that you don't have to really worry about which imports you use anymore; just write the code and let it figure out the import lines for you (and re: you'd much prefer… - give it some time. You'll learn to <em>love</em> not worrying about imports). I'd say in 99% of cases that works perfectly well - even in a large GOPATH like Google's :)</p>
<p>If it really doesn't work for you and you get annoyed, you can add a <code>var _ *bitstream.BitReader</code> at the package scope during experimenting, which counts as a usage and will make goimports not delete the import anymore. But really, you should figure out how to make it work to your advantage :)</p></pre>midnightFreddie: <pre><blockquote>
<p>as long as you a) use the correct package name (for that particular package it's "bitstream", as evident from the header here and b)</p>
</blockquote>
<p>o_O</p>
<p>Thanks! I hadn't even realized I had this problem yet. What I was troubleshooting was <code>go-bitstream.NewReader()</code> because in the examples I've seen so far you use the last bit of the import path to reference package functions. I thought I was hung up on io.Reader, but you just made me notice I wasn't even using the right package name: <code>bitstream.NewReader()</code></p>
<p>And when I used that and hit save, this happened:</p>
<pre><code>package main
import (
"fmt"
"log"
"os"
"strings"
bitstream "github.com/dgryski/go-bitstream"
)
</code></pre>
<p>Thanks again!</p></pre>TheMerovius: <pre><p>That's one of the reasons why you shouldn't do that (i.e. have a different package-name than the last component of the path) :)
Anyway, I hope you learn to love goimports as the rest of the community does :) And welcome to the community, while we're at it :)</p></pre>RandNho: <pre><p>I think best option on that stage would be to go and switch default formatter from goimports to gofmt in settings.</p></pre>szabba: <pre><p>That's one way to go about it, certainly. With third party packages goimports can not only take a long time, but also import the wrong one (when multiple have the same package name).</p></pre>TheMerovius: <pre><blockquote>
<p>when multiple have the same package name</p>
</blockquote>
<p>…and the same functions, and types. That really shouldn't happen very often. In practice, I manually have to edit imports approximately only when importing them under different names (e.g. for generated proto packages, which have annoying names).</p></pre>szabba: <pre><p>The go-gl binding suffer from this too!</p></pre>KSubedi: <pre><p>do a <code>go get</code> on the repository url of <code>go-bitstream</code> and it should auto detect things from there</p></pre>midnightFreddie: <pre><p>Ok, thanks.</p>
<p>Personally I'd much rather get an error than have it delete code, but that's between me and my VSCode extensions I suppose.</p></pre>aboukirev: <pre><p>In default settings the "go.formatTool" setting is "goreturns", which causes automatic handling of imports depending on usage. If you override that with "gofmt" in your user settings, then it won't delete the import line but instead will highlight it with red squiggle as an error (unused imported package). I' personally, much prefer the latter behavior.</p></pre>SeerUD: <pre><p>If you can get <code>goimports</code> set up then that should automatically add and remove them.</p></pre>
