GitHub依存は卒業しよう！Goプロジェクトをポータブルに保つためのベストプラクティス

Goプロジェクトにおいて、GitHubのURLを直接インポートパスに含めてコードを密結合させるのは、長期的なメンテナンスの観点から推奨されません。GitHubのURLに依存してしまうと、将来的にリポジトリを移動させたり、別のプラットフォームに移行したりする際に、Go Modulesのエコシステム内で面倒な作業が発生する可能性があります。代わりに、独自のドメインや、リポジトリのホスティング先に依存しない汎用的なインポートパスを採用することをおすすめします。これにより、コードの移植性が飛躍的に高まります。

GitHubはほぼ永遠に近い存在。カスタムドメインは支払いをやめれば消えてしまうし、オープンソース開発者ならGitHubがなくなる可能性よりもドメインを維持できなくなる可能性の方が高いと思う。いつかみんな、依存関係をvendoringする時代に回帰するんだろうな。

個人的には、Goを使っている商用ソフトウェア開発チームはすべて、社内ライブラリやパッケージのネームスペースにカスタムドメインを使うべきだと思う。

「Go」という部分は除外してもいいかな。つまり、他のスタックでも同じことが言えると思うんだ。コードのコメントにGitHubのドメインリンクを使うことさえ、長期的には問題になる。移行が発生して、リンク先がどこも存在しなくなるような状況になればね。

URLを使うのは間違いな気がする。これはURNか、何らかの形のURIに最適だ。DNSをバックエンドにするURNでもいい（まあ、それだとURLに近いけど）。できれば、複数のリゾルバーが利用できて署名も付いた、もっと抽象的なものの方がいいね。

つまり、GitホスティングをGitLabに移したらコードを変更しなきゃいけないってことだ！

go.modファイルに "replace github.com/example/example => gitlab.com/example/example" と書くだけで全部そのまま動くよ。そこまでして心配するのは、実際には重要じゃないことに対する過剰な最適化じゃないかな。

これは素晴らしい。ドメインをちゃんと登録・管理する会社や個人にとっては、すごく理にかなってる。悲劇的ではあるけれど、GitHubが消滅したり、移転が必要になるようなポリシー変更をしないという保証はどこにもないからね。Goの仕組み上、パッケージ名とGitHubを紐づけてコミットすることは、単なるプル元以上の重みを持ってしまう。一つ懸念があるとすれば、例のNginx設定で301を返していることかな。もしリダイレクト先を変えたくなった場合、古いURL設定にアクセスしたブラウザは強制的に古い設定のリダイレクト先に飛ばされ続ける。go ... や curl なら問題ないけど、ChromeやFirefoxは301を永続的にキャッシュするからリダイレクトが壊れる。まあ、実務上問題になるかは微妙だけど。

確かに。でも使用するドメイン名には気をつけて。VeriSignが数千のドメインと一緒に、あなたのドメインを一方的に削除する可能性だってある[1]から。そうなったらまた振り出しだよ。

[1] https://neil.fraser.name/news/2026/09/03/

Goの利点の一つは、コードの取得先でネームスペースを管理できることだ。

それなのに、記事の残りの部分ではなぜそれが実用上「良い機能ではない」のかを説明しているよね。決して機能しないわけじゃないけど、これはGoが独自の判断で行った「小さなこと」の一つで、信者たちに「これは素晴らしいアイデアであり、他の言語はすべて間違っていた」と納得させたものだ。いくつか問題が出てきた今、公式なパッケージ名を持つことの利点を認める代わりに、「みんなNginxやGo Vanity URLsフォワーダーを使って自分のドメインを立てればいい」と言われているのが現状だよ。

会社が倒産してドメインが放置されると本当に厄介だね。次にそれを買い取った人間が、他人が依存しているソースコードを乗っ取ることになる。他のエコシステムですでに何度も見てきたけど、最悪の状況だよ。自分のドメインでパッケージを管理するなんて悪いアドバイスだ。Microsoftみたいに永続的に支払いを続けられるわけがない。この世に保証なんてないけど、会社が潰れたとき、自分のドメインの維持なんて真っ先に忘れ去られることだけは保証するよ。

「検索と置換」で解決すると思っている人向けの補足。例えば、A 1.2.3 が B 2.4.6 に依存し、B が C 0.1.1 に依存するプロジェクトを考えてみて。GitHubならこうなる。

module github.com/example/A
requires (
github.com/example/B 2.4.6
github.com/example/C 0.1.1
)

ここからどうするか選べるけど、どれを選んでも「古いリリースをビルドできる」か「全依存関係に変更を加えずに済む」のどちらも満たせない。一つの手は、末端のCをGitLabでリリースし、BをそのGitLab版のCに依存させること。これは前に進むにはいいけど、ロールバックしようとしたら、すべてのCをGitLab URLを使うように書き換えて、タグをすべて探し出し、再プッシュしなきゃいけない。さらにユーザーには、リリース済みのバイナリのハッシュが変わったことを通知する。これをすべてのリポジトリで繰り返す…これは簡単な作業じゃないよ。

正直、Googleはツールからリポジトリを指し示すとしても、パッケージ名を維持してリポジトリの場所を変更できるようなパッケージインデックスを最初から持つべきだったね。