15 min/d

ぼうずやのにっき

bouzuya/time-keeper-js 2.0.0 をつくった

bouzuya/time-keeper-js 2.0.0 をつくった。

bouzuya/time-keeper-js は TypeScript で書かれた simple な date-time library だ。特徴としては millisecond / summer time / day of week に対応していないこと。そして TypeScript で書かれていることによる型定義の恩恵だ。昨日まで 0.2.2 だったのだけど、それを 1.0.0 にして終了した。代わりにまったく新しい 2.0.0 として、ほとんどすべてを書きなおした。

2.0.0 の目的は bouzuya/bs-code のための使いやすい date-time library をつくることだ。

moment/moment は mutable で不必要に巨大だ。 date-fns/date-fns の個別の import は必要最小限な点で素晴らしいが、 time zone などの扱いが悪くいまひとつ使いづらい。ぼくの date-time library のひとつの理想は java.time / joda time のような immutable でそれぞれにきちんと型を設けたものなのだけど、そこまでやると一揃いでないと使いづらくなる。bouzuya/time-keeper-js はぼくにとって必要最小限の date-time library をつくろうとするものだ。

1.0.0 から 2.0.0 での変更点は次の 3 点。

  • moment への依存を削除した
  • DateTime class を削除し、DateTime interface に変更した
  • method ではなく function として提供し、個別で import できるようにした

唯一の class である DateTime を削除しつつ、 date-fns/date-fns のように個別に import して使えるようにした。1.0.0 までは immutable な DateTime class を提供する moment の wrapper だったが、 2.0.0 からは date-fns のような helper function を提供する薄い library になった。ReactiveX/rxjs でもそうだったが、必要な分だけを import できるのは良いことだ。賢い bundler なら file size を最小限に抑えられるし、巨大になりすぎることがない。利用者にとっての必要最小限の size にできる。

過去の API を引きずっておりいくつか不満な点がある。

get で time zone がとれない点は一貫性がないように思う。そもそも get などという汎用の field への accessor があっていいのかは謎だ。

format が固定的すぎる点も気になる。かといって moment の開始地点である汎用の formatter も必要ない。format の指定において型の恩恵を失うし、つまらない bug の温床になる。あの Twitter でさえ formatter の format 指定で bug を発生させていたことがある。

bouzuya/time-keeper-js は実態として DateTime という data とそれを操作する function を大量に提供する library だ。多くの data (type) を提供しない以上、java.time のようには行かないし、function 単位で読み込める immutable な moment にしかならないのかもしれない。

最後にこれだけは書いておきたい。これは yak shaving だ。