みなさんは開発環境のツール管理、どうしてますか？
私は業界に入って三年半ほど Homebrew を利用していましたが、
最近、「Nixの記事」や「みなさんのDotfilesの記事」を見かける機会が増えたのもあって、自身の開発環境のアップデートしたいなと感じていました。
かといって...。
Nixのような「完全な再現性」を求めて、独自の言語を覚える時間も気力も正直私は持ち合わせてないです。
そこで私は、開発ツール管理における「Homebrewの手軽さ」と「Nixのような宣言的な管理」が出来る「Mise」を選定しました。
今回は、その経緯や困った所等を記事にしたいと思います。
※ 本記事では mise の機能紹介は行いません
Miseとは
What is it?
Like asdf (or nvm or pyenv but for any language) it manages dev tools like node, python, cmake, terraform, and hundreds more.
Like direnv it manages environment variables for different project directories.
Like make it manages tasks used to build and test projects.
MiseのGithubから引用してきました。
要約すると。
「開発ツール管理」、「環境変数管理」、「タスクランナー」を兼ね備えたものって感じですね。
発音
Pronounced "MEEZ ahn plahs"
「ミーズ」です。
乗り換えた経緯 ~ Homebrewで困っていたこと ~
1. バージョンの管理が難しい
brew update brew upgradeでのツールの一括アップデートは便利ですが、
最新のバージョンではなく、「〇〇系」にしておきたい、みたいな指定が出来ないですよね。
2. 自分でインストールしたものなのか依存先パッケージなのかが判断できない
brew listで出力されるツール一覧だと、自分でインストールしたものなのか依存ツールなのか、
判別できないですよね。
package.jsonとpackage-lock.jsonみたいな判別が出来ないです。
もちろん、brew depsコマンド、brew useコマンドを利用することで依存があるのかを特定することは可能ですがかなり手間ですよね。
3. dotfiles化に違和感
「違和感」なので、感覚レベルのことを記事に書いて恐縮ですが。
brew listが自分が選択したパッケージ以外のものがリスト化されている以上、それをコードで管理することに違和感を覚えていました。
また、リスト化してファイルを作成した後、別環境で再現する用のスクリプトを実装するのも管理コストが高くなりますよね。
※ homebrew側に変更があった場合に、スクリプトの面倒も見なきゃいけなくなるのは手間ですし
4. ディレクトリ単位での環境分離
複数プロジェクトをコンテナを使わずホストマシンで開発している場合、nodeやgoなど、言語バージョンの切り替えが手間じゃないですか？
今どきだと、リモート開発 or コンテナ開発をすることが多いかもですが、
私の場合、「静的解析やフォーマットの実行はホストOSでさっとやってしまいたい」みたいな時がたまにありますので、
「プロジェクトディレクトリごとでツールのバージョンを指定すること」はマスト要件です。
そういったツールももちろんあって、
Node系だとvoltaやnvmが強いイメージあります。
ただ、「homebrewでnodeとvoltaをいれて、プロジェクトディレクトリではvolta指定のnodeを使う」って違和感覚えますよね。
Miseを選んだ理由
1. バージョンを指定できる
以下のようにツールのバージョン指定出来ます。
[tools]
go = "latest"
golangci-lint = "v2.7.2" # バージョン固定
node = "latest"
jq = "latest"
Homebrewだと「いつの間にかバージョンが上がっていて動かない」ということが発生しかないですが、
Miseなら使用するツールとバージョンをコードで明示できます。
このファイルを dotfiles で管理すれば、
PCを買い替えた際や開発用のリモートVMを立てた際でも mise installのみで必要な開発ツールがインストール出来ます。
# ツールのインストール
mise install
# ツールのバージョン更新
mise upgrade
2. OS設定のみにならずディレクトリ単位でのパッケージの管理が可能
「プロジェクトごとに異なるバージョンの開発ツールを使いたい」という要件が、設定ファイルを置くだけで完結します。
例えば、プロジェクトA（Node.js v18）とプロジェクトB（Node.js v20）を行き来する場合でも、
ディレクトリ移動するだけでMiseが自動で切り替えてくれます。
プロジェクトA
[tools]
node = "18.00.0"
プロジェクトB
[tools]
node = "20.10.0"
direnv や volta を個別に導入しなくても、
Mise一本で言語のバージョンやツールのバージョンの切り替えが完結出来るのが非常に体験が良いです。
3. タスクランナーの定義
Miseはタスクランナーの機能も持ってます。(makeのようなもの)
mise runで定義されたタスクを一覧表示・実行が可能です。
OSの日次、週次のメンテナンスタスクに私は活用してたりします。
それを例に紹介しますね。
[tasks.cleanup]
description = "システム全体のキャッシュ掃除"
run = """
echo "Cleaning Go cache..." && go clean -modcache -cache -testcache
echo "Cleaning Docker..." && docker system df && docker volume ls -qf dangling=true | xargs -r docker volume rm && docker images -f 'dangling=true' -q | xargs -r docker rmi && docker container prune --force --filter 'until=168h' && docker ps --filter 'status=exited' | grep 'weeks ago' | awk '{print $1}' | xargs -r docker rm && docker builder prune && docker system df
echo "Cleaning npm cache..." && npm cache clean --force
"""
[tasks.doctor]
run = "mise doctor && mise reshim"
4. シェルエイリアスの定義
miseでインストールした開発ツールに関しては、 mise でエイリアス登録したいですよね。
勿論、miseはエイリアス登録機能もついています。
私は以下のような指定をしています。
mr = "mise run"
d = "docker"
dc = "docker compose"
dps = "docker ps"
dpsa = "docker ps -a"
dst = "docker stats"
dil = "docker images"
dclog = "docker compose logs -f"
dex = "docker exec -it"
dcex = "docker compose exec -it"
drm = "docker rm"
dri = "docker rmi"
5. dotfiles化が出来る
私は、Miseのポータビリティがものすごく価値があるな、と感じています。
Dotfiles で管理しているMiseのconfig.tomlを、
OS内でMiseが読み込むようにシンボリックリンクを設定するのみで、Miseのセットアップができます。
私の場合ですが。
Dotfiles の初期化スクリプトに設定内容を書いております。参考までに記載させていただきますね。
# Create symlink for mise
ln -sfvn "$DOTFILES_DIR/mise" ~/.config/mise
mise install
移行で困ったこと・解決策
特に時間もかからずすんなり移行できました。
その中でも、少し手間だったポイントと読者が気になってそうなポイントをまとめたので記載させていただきます。
1. Docker
AIと壁打ちしながら移行計画を進めていたんですが、docker関係がかなり山場と踏んでいました。
具体的には以下の開発ツールが候補でした。
- lima
- colima
- docker cli
- docker compose
- docker buildx
確かに、「上記の5つのうち1つでも Miseが対応していない」となった場合、かなりめんどうだな と感じておりましたが、
問題なくMiseで管理することが出来ました。
docker compose のPATHについて
docker composeとdocker buildxについてですが、miseではインストール先が以下のようになっています。
% which docker compose
~/.local/share/mise/installs/docker-cli/29.2.1/docker/docker
そのため、バージョンアップデートのたびにパスが変更されるため、
都度、docker cliがサブコマンドとして認識するために、シンボリックリンクを貼る必要があります。
ln -s $(which docker-cli-plugin-docker-compose) ~/.docker/cli-plugins/docker-compose
ln -s $(which docker-cli-plugin-docker-buildx) ~/.docker/cli-plugins/docker-buildx
もしくは。
miseのtoolsが定義しているインストール時のpostinstall機能を使っても良いかも。
これだとアップデート後に自動でパスを通してくれます。今のところ困ったことはないです。
[tools]
lima = "latest"
colima = "latest"
docker-cli = "latest"
docker-compose = { version = "latest", postinstall = "ln -s $(which docker-cli-plugin-docker-compose) ~/.docker/cli-plugins/docker-compose" }
"aqua:docker/buildx" = { version = "latest", postinstall = "ln -s $(which docker-cli-plugin-docker-buildx) ~/.docker/cli-plugins/docker-buildx" }
2. GUIアプリの管理をどうするか
MiseはGUIアプリの管理は出来ませんので、選定時にどうしようか悩んだ所でした。
よくよく考えたら、私自身が今GUIアプリの管理必要性をさほど感じてないのかなぁとも。
その理由を以下にまとめますね。
理由
- 使用しているPCにさほどサードパーティのGUIアプリをインストールしていない
(なるべくしないようにしてる) - 使用しているGUIアプリの大半がバージョンアップデートの有無をアプリ上で知らせてくれる
- OS初期化・OS移行をすることが数年に一度の機会でしかない
ってことで、GUIアプリの管理は今回からしない方針に決めました。
まとめ
Miseを導入して「Homebrewの手軽さ」と「Nixのような宣言的管理」のいいとこ取りをすることが出来たな、と感じています。
今のところは乗り換えてよかったなと。
「開発環境のコード化に挑戦したいけどまだできてないよ...。でも難易度高そう。」という人には特にMiseはおすすめです。
Miseの「OSの開発ツール管理」、「プロジェクト単位での開発ツール管理」のシームレスな体験を私はものすごく気に入っています。
今回は「Mise移行体験記」のような感じの緩い記事になりましたが、この記事を読んでいただいたどなたかの開発環境がより豊かになるきっかけになれば幸いです。