dinkというDenoのモジュールマネージャーを作った
Denoのモジュール管理について考えるていたら、より汎用的な仕組みにしたくなった
使い方
dink いれるbash$ deno install dink https://denopkg.com/keroxp/dink/main.ts modules.json を作るmodules.json{
"https://deno.land/std": {
"version": "@v0.17.0",
"modules": ["/fs/mod.ts", "/fs/path.ts", "/flags/mod.ts"]
}
}dink実行する
bash$ dink -A
Linked: https://deno.land/std@v0.17.0/fs/mod.ts -> ./vendor/https/deno.land/std/fs/mod.ts
Linked: https://deno.land/std@v0.17.0/fs/path.ts -> ./vendor/https/deno.land/std/fs/path.ts
Linked: https://deno.land/std@v0.17.0/flags/mod.ts -> ./vendor/https/deno.land/std/flags/mod.ts vendor ディレクトリにこういうエイリアスファイルができるtxtvendor
https
deno.land
std
fs/mod.ts
fs/path.ts
flags/mod.ts中身はこうなってる
vendor/https/deno.land/std/fs/mod.tsexport * from "https://deno.land/std@v0.17.0/fs/mod.ts"ESMのモジュールアグリゲーションを使い、
module.json に記載されたバージョンprefixを挿入したURLをexportしているこうすることで使う側からはバージョンを固定しなくても良くなる
index.tsimport * fs from "./vendor/https/deno.land/std/fs/mod.ts"というのはdemと同じなのだけど…
dinkはdemと異なり、
module.json しかみない dink しかコマンドがないリダイレクト先を探してリンクしてくれる
json{
"https://denopkg.com/keroxp/servest": {
"version": "@v0.10.0",
"modules": ["/server.ts"]
}
}こういうモジュールのエイリアスはこうなる（denopkg.comはraw.gihubusercontent.comにリダイレクトするので）
vendor/https/denopkg.com/keroxp/servest/server.tsexport * from "https://raw.githubusercontent.com/keroxp/servest/v0.10.0/server.ts"この実態ファイルを特定してリンクできるのはかなりメリットがある
Denoはurlモジュールがリダイレクトされた場合、そのリダイレクト先にファイルを保存してしまう
のでtsconfig.jsonのpath記述ではこのリダイレクトを追えなくてコードジャンプが使えないというデメリットがある
urlとDenoのキャッシュファイルが対応するとIntelliJのコードジャンプが使えるので大変便利
