4 ms·

What are you talking about? How is unused imports related to library versioning? And how is focusing on improving build times orthogonal to "building"? The conc

• lobster_johnson 11y ago
  You clearly didn't read what I wrote. First, Go doesn't have any concept of "releasing". "go get" just (1) just grabs the latest HEAD from whatever repo you're using, and (2) follows import paths. It doesn't even use release tags. So the "build times are affected by unused imports in dependencies" problem only exists as a hypothetical issue because "go get" implicitly trusts dependencies' import statements. Other package systems don't do this. They (RubyGems and NPM are good examples) require that you build a release that you then publish. Included in such a release is a dependency manifest (Gemfile.lock, npm-shrinkwrap.json) that the package manager can read. The more natural solution is to generate a dependency manifest at release time that only includes valid imports, and refuse to release something that contains unused imports. The build time issue only exists locally if you run a monorepo like Google's, and in that case it's my opinion that, just like code linting, this is your own concern, not something to pollute an entire developer ecosystem with.