Linuxes

mise.tomlの値をスクリプトから取得したい mise.tomlの特定の値をシェルスクリプトから取得したい場合、catしてgrepやawkで抜き出すのは手間である。mise config getは、mise.tomlの任意のキーの値をドット区切りのパスで取得するコマンドである。【mise】mise setでmise.tomlに環境変数を設定する が[env]専用なのに対し、mise config getはmise.tomlのどのセクションのキーでも取得できる。

モノレポ内のサブプロジェクト同士の依存関係を把握したい npm workspacesやCargo workspaceでモノレポを組んでいると、どのサブプロジェクトがどのサブプロジェクトに依存しているか把握しづらくなる。mise tasks graphは、モノレポ内のサブプロジェクトとその依存関係を可視化するコマンドである。2026年9月時点では実験的機能に位置づけられている。

タスクの設定ミスは実行するまで気づきにくい mise.tomlのタスク定義で、存在しないタスク名をdependsに書き間違えたり、aliasが別のタスクと重複したりしても、mise runで実際に実行するまで気づきにくい。mise tasks validateは、こうしたタスク定義の問題を実行せずにまとめて検出するコマンドである。

タスクが増えると依存関係を把握しづらい 【mise】mise tasks lsでタスク一覧を詳しく確認する では各タスクの一覧は分かるが、どのタスクがどのタスクに依存しているかまでは分からない。mise tasks depsは、タスクの依存関係をツリー形式で可視化するコマンドである。

タスク一覧だけでは中身まで分からない 【mise】mise tasks lsでタスク一覧を詳しく確認する でタスクの一覧は確認できるが、1件のタスクが具体的にどんなコマンドを実行し、何に依存しているかまでは分からない。mise tasks infoは、指定した1件のタスクの詳細情報を表示するコマンドである。

タスクの中身を編集するたびにファイルパスを調べるのが面倒 【mise】mise tasks addでmise.tomlにタスクを追加する で追加したタスクを後から編集する際、mise.tomlのどこにあるか、あるいはmise-tasks/のどのファイルかを探すのは手間である。mise tasks editは、タスク名を指定するだけで環境変数$EDITORにそのタスクを開くコマンドである。

タスクを追加するたびにmise.tomlを手で編集するのが面倒 【mise】mise runでタスクを定義して実行する でタスクを実行できるが、新しいタスクを追加するたびにmise.tomlの[tasks.*]セクションをTOMLの文法通り手で書くのは手間である。mise tasks addは、コマンドラインからタスクを追加できるコマンドである。

ツール1つのバージョンを変えるだけでDockerのレイヤーが全部作り直しになる Dockerfileでツールをインストールすると、途中のRUN命令でバージョンを1つ変えただけでも、それより上のレイヤーがすべて無効化されてビルドし直しになる。mise ociは、mise.tomlに書いたツールをそれぞれ独立したOCIレイヤーとしてビルドするコマンドである。ツール1つのバージョンを変えても、そのツールのレイヤーだけが再構築され、他のツールやベースイメージのレイヤーはそのまま再利用される。2026年9月時点では実験的機能に位置づけられている。

npm installを忘れてタスクを実行してしまう package-lock.jsonが更新されているのにnpm installを忘れたままmise runでタスクを実行し、依存関係の不足でエラーになった経験がある。mise depsは、ロックファイルがインストール済みの出力(node_modulesなど)より新しいかどうかを検知し、必要な場合だけ依存関係のインストールコマンドを実行するコマンドである。2026年9月時点では実験的機能に位置づけられている。

mise runを省略してタスクを直接実行したい mise.tomlにタスクを定義するとmise run <task>で実行できるが、プロジェクトのcontributorに./bin/testのような見慣れたコマンドとして使わせたい場合がある。mise generate task-stubsは、定義済みの各タスクに対応する実行ファイル(シム)を生成するコマンドである。