Reasons to prefer vanity URLs for GoLang packages

 January 18, 2019

Golang forces its users to use the repository URL of the dependency in the import statement.

For instance, if we want to import the “test” package that is hosted at github.com/fale/test, we will need to use github.com/fale/test. On the one hand, this is very nice since it allows anyone reading the code to immediately understand where the code is hosted and therefore find it very quickly. Also, this URL-based import path guarantees that no two different packages can have the same import path, preventing this kind of confusion for both programmers and the compiler itself. On the other hand, this is a limitation since it makes the code very reliant on the repository location.

This reliance might be problematic in many cases. The first one that pops in my mind (since it is the one that triggered this problem for me) is a company that has all its code hosted on a specific website (for example, github.com), but then it decides to move it to a different website (for example, gitlab.com).

The typical Golang configuration would require walking through all the files that depend on the moving package to replace the import path. This substitution obviously can be automated in many ways, but it would still be better to unbundle those two concepts.

The nice thing about how this process works is that Go will look for an HTML metatag, and therefore the package can share the URL with a webpage that can contain (un)related content. To be more precise, Go will look for the following metatag:

<meta name="go-import" content="{{ vanity_utl }} git {{ git_url }}">

To see how I usually handle those headers, you can look at my previous blog post on the topic.