deno に出会うまで

ドメイン駆動設計やマイクロサービスアーキテクチャの自習のために保険業務アプリでも自作してみようという試みを初めてみる。仕事ではゴリゴリに java を使用しているけれど。プライベートでも java だとオモシロクナイ。バックエンドだけでなくフロントエンドも触りたいので、javascript のランタイムである node.js を最初は使っていた。

しかし、どうも node.js 作った人が新しい javascript ランタイムを作り始めたらしいと聞き、deno と出会う。どうせプライベートだし、新しいものに飛びついてしまえと deno を使いはじめる。

依存関係ってどうやって管理するの？

node.js の後悔から package.json を捨て去ってしまったdeno。その代わりに import 文に URL を書けるんだよと言われても...。Don't Repeat Myself!、React の CDN のパスを至るところに書きたくないよ！バージョン上がったら、そうするんだ！

管理用ファイルを作る

そんなときは deps.ts というファイルに依存関係を書いてしまおうというのが現状のベストプラクティスのようである。
例えば、oakserver という koa の deno 版の deps.ts は以下のように記載されている。

deps.ts

export { copyBytes, equal } from "https://deno.land/std@0.67.0/bytes/mod.ts";
export { Sha1 } from "https://deno.land/std@0.67.0/hash/sha1.ts";
export { HmacSha256 } from "https://deno.land/std@0.67.0/hash/sha256.ts";
export { serve, serveTLS } from "https://deno.land/std@0.67.0/http/server.ts";
...

外部ライブラリを使用する場合はこの deps.ts から必要なクラスなどをインポートすれば良い。package.json の devDependency に対応する依存関係を管理するのであれば deps_dev.ts などのファイルに記載すれば良い。alosaur という NestJS ライクなフレームワークでは deps_test.ts というファイルをテストランナーを管理するために別途用意している。

ライブラリではなく、純粋なアプリケーションとして使用するものであれば import maps というものでも良い。その場合、各ソースファイルの import 文の記載は node.js 時代のものと似たような書き方になる。繰り返すが、ライブラリとして公開するようなものには使えないので注意が必要である。

アップデートは？

現状では、3rd party 製のソフトウェアの力を借りなければならない。deps.ts で依存関係を管理する場合、dmm が、import map で管理するのであれば、Trex というソフトウェアがそれぞれ役に立ちそうである。まだまだ、十分に成熟したデファクトスタンダードな依存関係管理ソフトウェアは deno には無いが、どちらもシンプルな仕様なので今後なにか新しいものが登場しても後悔することはないであろうと思う。

まだまだこれから

deps.ts で管理するにせよ import map で管理するにせよ、バージョンを範囲指定するための仕組みは必要であるが、package.json のチルダやキャレットを使用したバージョン指定のような仕組みが deno やその周辺には現状存在しない。