時刻ベースのセマンティックバージョン生成

インクリメンタルなバージョニングではなく、ビルドやデプロイの時刻をそのままバージョン番号にしたい場面がある。特に Chrome 拡張機能などはバージョンの最大値が 65535 に制限されているため、時刻を適切に変換する必要がある。

コード

type SemanticVersion = `${string}.${string}.${string}`;

function timeBasedSemanticVersion(): SemanticVersion {
  const now = new Date();

  const major = now.getFullYear();
  // 上二桁を月、下二桁を日として扱う
  const minor = `${(now.getMonth() + 1) * 100 + now.getDate()}`;

  const hh = `${now.getHours()}`;
  const mm = `${now.getMinutes()}`.padStart(2, "0");
  const s = `${now.getSeconds()}`.slice(-1);
  const patch = `${hh}${mm}${s}`;

  return `${major}.${minor}.${patch}`;
}

使用例

console.log(timeBasedSemanticVersion());
// 2026.0214.14305 (2026年2月14日 14時30分50秒の場合)

仕様

major: 年（YYYY）- 2026 など
minor: 月日（MMDD）- 0214 など。最大 1231 なので 65535 制限に収まる
patch: 時分秒の下一桁（hhmms）- 14305 など。最大 23595 なので制限内

プレリリースタグやビルドメタデータはサポートしていない。純粋な SemVer ではなく、時刻を読みやすくエンコードした形式だ。

代替アプローチ

この方式の問題は、同じ日の複数ビルドで時刻が逆転するとバージョンが下がる可能性がある点だ。より厳密に管理したい場合は以下を検討する：

git コミットハッシュの短縮形（一意性は高いが時刻情報が失われる）
CI/CD のビルド番号（連続性はあるがプロバイダ依存）
日時 + ビルド番号の組み合わせ

時刻ベースのメリットは、ビルド時刻が一目でわかる点だ。デバッグやトラブルシューティングで有効だ。