mise を GitHub Actions にも導入するにあたって、少し詰まったことがあったのと、導入して良さそうに思ったことをまとめます。
mise とは
mise-en-place documentation
mise.jdx.devmise は、開発環境のツールバージョン管理ツールです。 以前は なんとかenv などで管理していた言語のバージョン管理に加えて、npm などでインストールできるツールも一括で管理できます。
また、mise にはタスクランナーとしての側面もあります。個人的にはこれが結構気に入っていてます。
私は JS で開発することが多いのですが、package.json だと複雑なコマンドを定義しづらいので、最近は mise で定義することも増えてきました。
以下のように toml で開発環境の設定をまとめることができます。
# ツールの管理[tools]node = "24.13.0"gh = "latest""npm:npm-check-updates" = "19.3.2"
# 環境変数の管理[env]NODE_ENV = "development"
# タスクの管理[tasks.clean]run = ["rm -rf node_modules", "rm package-lock.json"]
[tasks.clean-install]description = "説明も書けます"depends = ["clean"] # コメントも書けるrun = ["npm install"]GitHub Actions での導入
mise でのバージョン管理を本格導入する場合、GitHub Actions などの CI 環境にも導入したくなります。
導入自体は簡単で jdx/mise-action を使うだけです。
jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: jdx/mise-action@v3 # 以降、mise でインストールされたツールを利用可能問題
導入自体は簡単なのですが、単に入れると開発環境でしか使わないツールまでインストールされるため、次のような問題が発生します。
- 特にキャッシュがない場合に action の実行時間が長くなる
- キャッシュのサイズが大きくなる
- 開発用のツールのインストールことで問題が発生する可能性もあるかも
解決法
mise v2026.1.1 で導入された
.miserc.toml と MISE_ENV
環境変数を使う方法で解決できます。
この機能を使い mise の設定ファイルを分割して、環境ごとに必要なツールを分けたり、共通化したりします。
.miserc.toml は MISE_ENV を設定するためだけのファイルです。
MISE_ENV は読み込む設定ファイルを切り替えるためのもので、以下の優先順位で設定ファイルが読み込まれます。
mise.{MISE_ENV}.local.tomlmise.local.tomlmise.{MISE_ENV}.tomlmise.toml
例えば、以下のように設定します。
env = ["development"]# 共通設定[tools]node = "24.13.0"# 開発環境専用設定[tools]"npm:npm-check-updates" = "19.3.2"gh = "latest"GitHub Actions 側では MISE_ENV を ci に設定することで、CI 用のツール定義もできます
# CI 環境専用設定[tools]# ここには CI 専用のツールを定義できますjobs: build: runs-on: ubuntu-latest env: MISE_ENV: ci # CI 環境を指定 steps: - uses: actions/checkout@v6 - uses: jdx/mise-action@v3 # 以降、mise でインストールされたツールを利用可能実際に導入してみたものもあるので、参考として載せておきます
Contribute to nabekou29/js-i18n-language-server development by creating an account on GitHub.
github.comRust のプロジェクトで、実行コマンドも mise のタスクで統一 しています。
良かったこと
開発環境と CI 環境でバージョンを確実に統一できる
mise を使わずとも、 例えば node を使っていれば、package.json の engines フィールドでバージョンを指定すると、actions/setup-node で同じバージョンを使うことができます。
しかし、別の言語やツールについては都度調べる必要がありますし、場合によってはバージョンを actions 側で指定しないといけないこともあるかもしれません。
そういった煩わしさがなくなるのは、大きなメリットです。
タスクを mise に集約しつつもノイズがない
CI 用のコマンドが開発環境と微妙に差分があるのはよくあると思います。引数がちょっと違ったり。
そんな時に mise.ci.toml に CI 用のタスクを定義しておけば、mise.[development.]toml
と近い位置にタスクを定義できるので、管理がしやすいです。
その上で、開発環境では mise.ci.toml は読み込まれないため、mise run
の一覧や補完結果に入ってくることもないので、ノイズにもならずに済みます。
地味に嬉しい。
ファイルが分割されてしまうのは、若干好みの別れるところのような気もします。