整合性チェックとロックファイル

導入

あなたのモジュールがリモートモジュール https://some.url/a.ts に依存しているとしましょう。 初めてモジュールをコンパイルするとき a.ts が取得され、コンパイルされ、キャッシュされます。 そのモジュールを新たなマシーン（本番環境など）で実行するかキャッシュをリロードする（たとえば deno cache --reload で）ときまでキャッシュは残ります。 しかし、もしリモート URL https://some.url/a.ts の中身が変更されるとしたら何が起きるでしょうか？　これが起きると本番環境のモジュールがローカルのモジュールと異なるコードで実行される可能性があります。 Deno はこれを回避する解決策として整合性チェックとロックファイルを用意しています。

キャッシュとロックファイル

Deno は小さな JSON ファイルを使ってモジュールのサブリソースの整合性を保存し、チェックできます。 --lock=lock.json を指定するとロックファイルによるチェックを有効化できます。 ロックファイルを更新または新規作成するには --lock=lock.json --lock-write を指定します。 --lock=lock.json は Deno にどのロックファイルを使うかを教え、--lock-write は依存関係のハッシュをロックファイルに出力するために使います （--lock-write は --lock と一緒に使う必要があります）。

lock.json は次のように依存関係に対してファイルのハッシュ値を保存するものです。

{
  "https://deno.land/std@$STD_VERSION/textproto/mod.ts": "3118d7a42c03c242c5a49c2ad91c8396110e14acca1324e7aaefd31a999b71a4",
  "https://deno.land/std@$STD_VERSION/io/util.ts": "ae133d310a0fdcf298cea7bc09a599c49acb616d34e148e263bcb02976f80dee",
  "https://deno.land/std@$STD_VERSION/async/delay.ts": "35957d585a6e3dd87706858fb1d6b551cb278271b03f52c5a2cb70e65e00c26a",
   ...
}

典型的なワークフローは次のようになります。

src/deps.ts

// 新たな依存関係を "src/deps.ts" に追加し、別の場所で使用します
export { xyz } from "https://unpkg.com/xyz-lib@v0.9.0/lib.ts";

次。

# ロックファイル "lock.json" を作成／更新します
deno cache --lock=lock.json --lock-write src/deps.ts

# コミットしてソース管理下に置きます
git add -u lock.json
git commit -m "feat: Add support for xyz using xyz-lib"
git push

別の作業者が別のマシンで新たにプロジェクトをクローンします。

# プロジェクトの依存関係をマシンのキャッシュにダウンロードし、
# 各リソースについて整合性をチェックします
deno cache --reload --lock=lock.json src/deps.ts

# 完了です！　安全に作業を続けられます
deno test --allow-read src

実行時の検証

上記のキャッシュと同じように deno run サブコマンドの使用時にも、--lock=lock.json オプションを使って、実行中のモジュールの整合性を検証できます。 ここで行われる検証は、以前に lock.json ファイルに追加された依存関係だけである点を頭に留めてください。 新たな依存関係はキャッシュされますが検証はされません。

リモートの依存関係がキャッシュ済みであることを --cached-only フラグを使えばこれを一ステップで行えます。

deno run --lock=lock.json --cached-only mod.ts

mod.ts の依存関係のツリーに一つでもキャッシュされていないものがあればこのコマンドは失敗します。