前回の記事を書いた時点では、Deno 向けの Inspired by zx な何かよりはオリジナルの zx のほうがよいだろうと考えていた (し今も無難なのは zx だと思う) のだが、dax が比較的よさそうだったので試している。

まず、Deno であることによって、いきなり TypeScript で書けたり、package.json が不要だったり、スタンドアロンのバイナリを生成できたりといった利点があるというのは前回も触れた通り。

import $ from "https://deno.land/x/[email protected]/mod.ts"

await $`echo "Hello, World!"`

deno run -A hello.ts # => Hello, World!

deno compile -A hello.ts
./hello # => Hello, World!

VSCode での開発も、Deno の拡張機能を入れればスムーズ。

加えて dax ならではだと思うのが、クロスプラットフォームであるということ。

zx は Node 向けに書かれているので、Node が動けばどこでも動く、かと思いきや、$ で外部コマンドを実行する際に child_process.spawn を使用するため、シェルに依存している。

一方、dax では deno_task_shell という deno task コマンド (npm scripts 的なもの) のために書かれた Deno 独自のクロスプラットフォームなシェルの実装を使っている。しかも、いくつかのコマンドは TypeScript で再実装しているという気合の入れよう。これによって、deno_task_shell がサポートする範囲であれば Windows でも macOS や Linux と同じスクリプトが動く。

なかなかぶっ飛んだことをしていると思うし、これが dax のために完全に独自実装していると言われたらちょっと使いたくないが、Deno 本体でも使っている実装を流用しているというのがポイント。それならまあ大丈夫なのかなという気持ちにさせてくれる。

どうやら dax の開発者がそもそも Deno Land Inc で deno_task_shell を開発しているようなので、そういう意味でもなんとなくの安心感がある。

# このへんふわっとしたことを言っているが、本当にプロジェクトの継続性を考えるなら素直に Star の多い zx がいい気がする。

なお、Inspired by zx ではあるが、あくまでも Inspired であって、互換性は特に無いので注意が必要。zx 向けに書いたスクリプトは結構書き換えないと dax では動かなかった。