VSCodeの設定

VSCode向けの環境構築手順はおそらく以下の通りになります。

1. deno(.exe)をどっかから持って来て$PATHに入れる

   公式が推奨するインストール方法

   deno(.exe)さえあればいいので、GitHub Actionsから持って来るなりしてもよいです。なんならcargo installでも普通に入ります。Denoにはセルフアップデート機能があるので、適当な入れ方をして適当な場所に置いても特に問題はないはず。

   あとLinuxディストロによっては標準のパッケージマネージャーに入っていることがあります。

   deno(.exe)にフォーマット機能もリント機能も同梱されているので、スクリプトを動かすだけならここまででも十分かと思います。

2. denoland.vscode-denoをインストール

   この拡張機能はdeno(.exe)を同梱しません。そのため1.の手順は必須です。

3. VSCodeのワークスペースを設定

   Denoが拡張子に.tsを用いていることもあり、vscode-denoはデフォルトでは動作しないようになっています。そのため次のどちらかを設定する必要があります。

   • Denoのことだけを考えればよいリポジトリの場合: "deno.enable": true
   • Node.jsも使うリポジトリの場合: "deno.enablePaths": [...Nodeではない、Denoのスクリプトへのパス]

   .vscode/settings.jsonをこのリポジトリに入れればこの手順はスキップできるのですが、このファイルは通常gitignoreして個々人が自分用の設定を追加するのが慣習的なのではないかとも思っています。私は普段Python以外にVSCodeを使っていないので、この辺の感覚がよくわかっていません。

VSCode以外の設定

VSCode以外だと、どちらかというとNode.js用設定との共存が面倒かなと思っています。

私はNeovimでnvim-lspconfigを使っているのですが、以下の設定で少なくともリポジトリ単位での使い分けはなんとかなっています。

local lspconfig = require('lspconfig')

lspconfig.denols.setup {}

lspconfig.tsserver.setup {
  root_dir = lspconfig.util.root_pattern("package.json", "tsconfig.json", "jsconfig.json"),
  single_file_support = false,
}

nvim-lspconfig以外の(Neo)Vimの設定例として、Node.jsとDenoを両方使っていらっしゃるであろうNanashi.さんとらぁさんの設定も見てみたのですが、馴染みがないのでよくわからなかったです。

• Nanashi.さんの設定: https://github.com/sevenc-nanashi/dotfiles (Neovim + coc.nvim + coc.deno?)
• らぁさんの設定: https://github.com/raa0121/dotfiles (Vim + vim-lsp?)

自分はcoc-tsdetectを使っていますね。（参照：coc-package.json:12）

なるほどcocにはそんなのが…

詳細ありがとうございます！！

正直なところ、Denoというかなりマイナーな環境を採用すべきなのかどうかという点でかなり迷っています。

・仕様周りが高頻度で変わるのではと思っていてメンテナンスコストが高くなりそう？
・補助スクリプトというあまり変化しなそうなところのために一風変わった環境を用意してもらう必要がある
・主にコマンド実行が役割だけどそのあたりが逆に大変になる（zip解凍など）

２つ目はボイボ全体のスクリプトをDenoにするなどすれば軽減しそうですが、大変だよなーと…。
まとまってなくて申し訳ないのですが、所感はこんなかんじです🙇‍♂️

実行可能バイナリで配布したいならRustで作ってしまったほうが良かったのでは？coreのメンテナの習熟度や環境構築のことを考えるとそのほうが良いように感じました

Rustで書くことも考えたのですが利用者にCargoのインストールを要求するため、それならdeno.exeさえあればよくて読み書きできる人が多そうなDenoの方が楽かなと思っていました。ただ考えてみるとGitHub Releasesからバイナリを配るのなら、利用者はランタイムをインストールする必要が全くもって無いんですよね。

Bash/Python/Deno(TypeScript)と比べるとRustを読み書きできる人は少なくなるというのも理由としてありましたが、それも極端な話私とqwertyさんとSuitCaseさんができればいいわけですし。

私個人としてはRustで書いたとしてもBashやPythonやDenoと比べ、読み書きしやすさが低下するという感覚は無いです。もしRustでもよいのなら、このPRを即座にcloseしてRustで書き直す用意はできています。

@qryxip そうですね。cargoのインストールが必要なのは利用者ではなく開発者なのでRustで書いても配布については問題ないはずです。
開発についてもそもそもこのリポジトリで貢献しようとする人はcargoをインストールしてるはずなので問題ないと思います。
最終的な判断はhihoさんになるとおもいますが

うーーーーーん、判断が難しいですね！！

正直なところ、シェルスクリプトでも十分可能なことをRustで書くのは流石にオーバースペック感あります。
ビルド周りも含めないとなので、シェルスクリプトに比べてメンテコストは同じくらいかちょい高いくらいかなという直感です。
あと今思えばlatest版ビルドを用意できてないのでちょい大変になりそうです。

モチベは shell script >>> Rust > Deno って感じです。（shell scriptが高いのはすでにあるからです。）
できれば、今できてないとこを作るのに注力したい気持ちがあります。（DirectMLのGPU自動選択を良くするとか。）

という総合判断でたぶんやめたほうがいいだろうなという直感です…！🙇‍♂️
（latestビルドが無いというのが一番のボトルネックかなと…！気付くのが遅れて申し訳ないです…🙇‍♂️）

いや、latest版がほしくなるのは主に開発者で、開発者はcargo使えるから自分でビルドできますね。
OS環境依存もある程度排除できるので、Rust化はありかもと感じてきました。

ちなみになのですが、いざとなったらシェルコマンドの実行が視野に入ってくると思います。
Rustからコマンドを叩くのは難しかったりしますか･･･？ 👀

こんな感じでいけるのではないかと。

use std::path::Path;

use duct::cmd;

fn extract_tgz(tgz: &Path, extract_dir: &Path) -> anyhow::Result<()> {
    cmd!("tar", "xvf", tgz, "-C", extract_dir, "--strip-components=1").run()?;
    Ok(())
}

なるほどです、簡単そうですね！！
Rustでダウンローダー、ありな気がしてきました！もしよければPR頂ければ！！

もし万が一実際のコードがあまりにも複雑に感じたら再考で…！🙇‍♂️
（よっぽどのことがない限り大丈夫かなという気持ちです）

はい。今晩作ってみようかと思います