Comments

Currently, the golang.org/x/tools/imports features some internal configuration options to make it possible to adjust it to run (in a limited capacity) in environments where there is no raw filesystem access (for example, App Engine):

// importPathToName returns the package name for the given import path.varimportPathToName = importPathToNameGoPath
// loadExports returns a list exports for a package.varloadExports = loadExportsGoPath
// findImport searches for a package with the given symbols.// If no package is found, findImport returns "".// Declared as a variable rather than a function so goimports can be easily// extended by adding a file with an init function.varfindImport = findImportGoPath

There's a few code generation files like mkindex.go to help pre-compute static indices of packages for such environments.

However, since those variables are unexported, the only current way to make changes there is to fork the entire golang.org/x/tools/imports package.

It's slightly more convenient in that a new file can be added with init() that overrides the internal variables, but the rest of the package will still be a fork that needs to be maintained and kept up to date.

Feature Request

What do you think about adding a means to override those internal configuration funcs (or provide your own implementations) and pre-computed indices. Perhaps via:

Or something like that, to make it possible to import golang.org/x/tools/imports and configure it to one's needs, without needing to fork it.

Additionally, it'd be great if the findImport, etc. implementations that currently rely on raw filesystem access and import low level packages like os could be moved into a separate file with a build tag like // +build !nacl to prevent them from being included on systems where those low level packages are not available.

Some context on where I'd like to use this can seen in gopherjs/gopherjs.github.io@40f830c, where I had to fork imports and customize for the GopherJS Playground. Since the code runs in a browser, a static index is used, and unused code importing os and sync is removed.

Because it makes internal implementation details a part of the API, making it harder to change.

Perhaps instead of exposing all internal details, imports could use build tags to have a fallback mode where it uses the pre-computed index of standard library for environments without raw filesystem access, and just a way of setting/adding to that pre-computed index.