正直、ターミナルを触っているだけで少し楽しい。黒い画面にコマンドを打って、rgでコードを探し、Neovimで直す。SF映画のハッキングシーンみたいで格好いい。効率だけで選んだわけではありません。PC操作が退屈ではなくなる。
AIにコードを書かせる機会が増えた今でも、読む、探す、直す、確かめる部分は自分で触っていたい。ただ、WindowsとWSL2の両方に同じツールが入り、どちらのNode.jsやPythonが動いているのか分からない状態では、気持ちよさより手戻りが勝ちます。
そこで、Windowsは操作席、WSL2は開発場所と決めました。言語ランタイムはmiseへ寄せ、プロジェクトの依存関係は言語ごとの道具へ任せる。いまの結論はこれです。
Windowsを操作席、WSL2を開発場所にした
今の構成は単純です。
| 場所 | 担当 |
|---|---|
| Windows | WezTerm、GUIアプリ、IDE、Docker Desktop、Windows固有の操作 |
| WSL2 | リポジトリ、Git、言語ランタイム、CLI、Neovim |
メインターミナルはWezTermです。Windows側で起動して、WSL2のシェルに入る入口として使っています。WezTerm自体の設定は以前にWin11でWezTermの設定をした話へ書きました。
リポジトリはWSL2の~/projects/example-appのようなLinux側に置きます。Windows側のGUIを使いながら、実際にコードを読む・編集する・テストを回す場所はLinux側です。CodexもこのWSL2のワークスペースで使っています。
例外は、Windowsのターミナルを直接使う別PCです。そこにはWindows版Yaziも入れました。ただし、WSL2からWindows版のCLIを呼ぶ運用にはしていません。見た目が同じコマンドでも、WindowsとLinuxでは別物として扱います。
ランタイムはmise、依存関係は各言語の道具へ任せた
miseは、Node.jsや.NET SDKなどのバージョンをそろえるための道具です。私の環境では、Zshの起動時にmise activate zshを読み込み、nodeやdotnetを実行すると設定したバージョンへつながります。
ここで扱うのは、ランタイムやCLIのバージョンまで。TypeScriptプロジェクトの依存関係はpnpm、Pythonはuv、.NETはNuGetが担当します。この線を引いたら、構成がかなり見やすくなりました。
WSL2側では、言語ランタイムをmiseへ寄せました。現時点でmiseのグローバル設定に登録している言語ランタイムは、.NET SDK、Node.js、Go、Pythonです。
pnpmはNode.js用のパッケージマネージャー、YaziはCLIなので、どちらも言語ランタイムではありません。それでも現在はmiseでバージョンを固定しています。これは管理を一か所で確認したかったためで、何でもmiseへ寄せるという意味ではありません。
一方で、miseに何もかも任せるわけではありません。Pythonは、miseでPython本体を用意し、プロジェクトごとの仮想環境と依存関係はuvで管理することにしました。
mise : Node.js / .NET SDK / Go / Python本体 / pnpm / Yazi
uv : Pythonプロジェクトの .venv、依存関係、Ruff
pnpm : TypeScriptプロジェクトの依存関係
NuGet : .NETプロジェクトの依存関係
uvはプロジェクトごとに.venvを扱い、uv runでその環境のコマンドを実行できます。uvの公式ガイドも確認し、Python本体とプロジェクトの依存関係は分けて管理することにしました。
Node.jsでは、以前のnvmをアンインストールせずに残しています。ただしシェル起動時のnvm読み込みは止めました。nvmが先に有効になると、miseとどちらのNode.jsを使っているのか曖昧になるためです。削除より先に自動読み込みだけを外したのは、問題があった時に戻れるようにしたかったからです。
miseは.nvmrcやglobal.jsonのような、言語ごとのバージョンファイルも読めます。公式ドキュメントを確認し、私の設定ではNode.jsと.NETだけを対象にしました。既存プロジェクトの指定を、mise用の書式へ無理に書き換えずに済んでいます。
先に確認するコマンドを決めた
環境構築後にまず見るのは、インストール済みかではなく、何が実行されるかです。
command -v node
command -v python
command -v dotnet
mise current
type -a node
この確認をしないと、Windows版の実行ファイル、nvm、mise、システムパッケージのどれが選ばれたのか分かりません。一度動いた、では足りない。翌日も同じコマンドが同じものを指す状態にしたかったのです。
いまは、AIに任せる範囲と自分で触る範囲が分かれた
AIには実装案や変更を作ってもらう。私はWezTermからWSL2へ入り、差分を読み、rgで周辺を探し、Neovimで必要な箇所を直してテストを回す。この分担が今はいちばんしっくりきています。
AIが実装を速くしても、私は全部を眺めているだけにはなりたくない。zでプロジェクトへ飛び、検索して、コードを追って、最後に自分でOKを出す。少し手間が残っているくらいが、触っていて楽しい。
YaziのWindows導入で詰まった点はYaziをWindowsとWSL2で使い分けたら、file.exeでつまずいた、LSPの調整はNeovimのLSPが動かない原因はプラグインではなくPATHだったへ分けました。実際の検索と確認の流れはAIにコードを書かせた後、rg・fzf・Yazi・Neovimで読むに続きます。
コメント