- mise が新しい モノレポタスク機能 を発表
- 複数プロジェクトで それぞれの環境、ツール、タスク を簡単に管理できる統合タスク名前空間を提供
- 強力なワイルドカードパターン、環境/ツール継承、一貫した実行コンテキストなど多様な機能を含む
- 多様な言語や複雑な環境を持つモノレポに シンプルさと柔軟性 を提供
- 既存の Bazel、Turborepo などと比べて 言語非依存、簡単な設定、統合管理 が強み
紹介: モノレポタスク機能の発表
- mise で モノレポタスク (Monorepo Tasks) という新機能を導入
- 複数プロジェクトを含むリポジトリで、各プロジェクトごとにツール、環境変数、タスクを独立して維持し、効率的に管理できる 本格的なモノレポ対応 を提供
主な機能
- 統合タスク名前空間: モノレポ内のすべてのタスクを自動検出し、場所ごとにプレフィックスを付けて明確に区別
例:
mise //projects/frontend:build
mise //services/api:deploy
- スマートなツールと環境の継承: ルートで共通ツールを定義し、必要に応じて下位プロジェクトで再定義可能
- 例: ルートの mise.toml の node=20、python=3.12 設定をすべての下位プロジェクトに自動継承
- 特定プロジェクト (mise.toml) で node=14 にオーバーライドでき、上位の python 設定は引き続き継承
- 強力なワイルドカードパターン:
- すべてのプロジェクトのテストを実行: mise //...:test
- services/ 以下のすべてのビルドを実行: mise //services/...:build
- frontend 内のすべてのタスクを実行: mise '//projects/frontend:*'
- タスク名に応じたグループ実行が可能
- どこでも一貫した実行: どの場所でタスクを実行しても、そのタスクの config_root で定義された環境とツールのまま実行
- 自動信頼伝播: モノレポのルートだけを Trust 登録すれば、下位構成は自動的に信頼される
クイックスタートガイド
- ルートの mise.toml で experimental_monorepo_root=true を設定
- 実験フラグ (MISE_EXPERIMENTAL=1) を有効化
- 各プロジェクトの mise.toml に tasks を追加
- 例:
[tasks.build]
run = "npm run build"
- ルートおよび任意のパスから目的のタスクを実行
- mise //projects/frontend:build
- mise //...:test
モノレポ構成の例
- myproject/
├── mise.toml (experimental_monorepo_root = true)
├── services/
│ ├── api/mise.toml
│ ├── worker/mise.toml
│ └── scheduler/mise.toml
└── apps/
├── web/mise.toml
└── mobile/mise.toml
- すべてのサービスのビルドを実行: mise //services/...:build
- すべてのアプリのテスト: mise //apps/...:test
- 全タスク: mise '//...:*'
導入の背景と効果
- モノレポ管理の 複雑さ と反復的なスクリプトへの課題意識から出発
- 一度定義してどこでも実行することで 重複を最小化
- 各プロジェクトごとに 正確なツール/環境を自動適用
- 強力なワイルドカードで CI/CD パイプラインを簡素化
- タスク名前空間 により探索性と理解しやすさが向上
既存の主要ツールとの比較
-
シンプルなタスクランナー (Taskfile、Just など)
- 単一プロジェクトの自動化に最適化されており、モノレポでは統合名前空間・継承・ワイルドカードをサポートしない
- mise は 自動タスク検出と強力なパターンサポート を提供
-
JavaScript 中心ツール (Nx、Turborepo、Lerna)
- JS/TS モノレポで強力 (dependency graph、codegen、cache など)
- mise は 言語非依存 で、多様な言語/スタックに対応し、統合されたツール/環境変数管理を支援
-
大規模ビルドシステム (Bazel、Buck2)
- 分散キャッシュ、リモート実行などを提供するが、複雑さと学習コスト が高く、構造上の制約も多い
- mise は 非 hermetic (non-hermetic) なアプローチで、柔軟な設定と容易な導入が可能
-
その他 (Rush、Moon など)
- Rush: JS 専用のビルド orchestration
- Moon: Rust ベースでマルチ言語対応志向
mise Monorepo Tasks の特長
| 機能 |
Simple Runners |
JS 専門 |
Build Systems |
mise |
| マルチ言語対応 |
✅ |
❌ |
✅ |
✅ |
| 学習のしやすさ |
✅ |
⚠️ |
❌ |
✅ |
| 統合タスク検出 |
❌ |
✅ |
✅ |
✅ |
| ワイルドカードパターン |
❌ |
⚠️ |
✅ |
✅ |
| ツールのバージョン管理 |
❌ |
❌ |
⚠️ |
✅ |
| 環境継承 |
❌ |
⚠️ |
❌ |
✅ |
| 最小限の設定 |
✅ |
⚠️ |
❌ |
✅ |
| タスクキャッシュ |
❌ |
✅ |
✅ |
❌ |
- どんなときに Mise を選ぶ べきか?
- 言語混在モノレポ
- 統合されたツールおよびタスク管理
- 簡潔さ を好む場合
- mise の利用経験者に適している
- 他の選択肢を検討 すべきとき
- JS/TS に特化 → Nx、Turborepo
- 超大規模エンタープライズ (Google/Meta など) → Bazel、Buck2
- 高度なタスクキャッシュが必要 → Nx、Turborepo、Bazel
結論
- mise の モノレポタスク機能 は単一言語に限定されず、多様な言語環境の複雑なモノレポを簡単かつ一貫して管理できるよう設計されている
- 最小限の設定と強力なタスクパターンにより、開発者の生産性と体験の両方を向上させる
- 複雑なエンタープライズ向けソリューションと比べて、はるかに簡潔で柔軟
2件のコメント
Mise - 多言語（Polyglot）バージョンマネージャー
Mise: 開発ツール、環境変数、タスクランナー
Hacker Newsの意見
以前は主にPythonを使っていたので、Miseの魅力があまりよく分からず、uvで十分だと思っていた
でもNodeのようにディレクトリごとにバージョンを合わせたり、言語やプロジェクトの種類に関係なく
mise buildやmise testのような共通エントリポイントが必要になったとき、Miseの真価を実感したJustもタスクランナーとして本当に気に入っていて、そのおかげでMakeから離れられた
Makeは強力だが、開発体験の面では物足りなさがあった
機能面ではJustのほうがMiseのtask機能より強力かもしれないが、Miseはかなり良いtask機能と優れたツール管理機能をあわせ持っていて、自分にとっては最高の組み合わせだ
シンプルなMakefileが好きな立場として気になるのだが、MakeからJustを経てMiseへ移る中で、どんな利点があったのか知りたい
justは本当に好きだったが、just taskで正確な環境を整えるのが面倒で、仮想環境を読み込むのも煩わしかった
なので似たような理由でmiseに乗り換えた
miseにはとても大きな期待を寄せている
新しいプロジェクトを始めるたびに、すぐ必須ツールの地位を占めるようになった
1つの設定ファイルでnode、python、rust、goなど複数のツール管理と、使いやすいmakefile代替をまとめて扱えるのでとても便利だ
たいていは
postinstallhook を設定しておき、誰かが自分のプロジェクトを取得したときにmise installだけ実行すれば、適切なツールのバージョンや依存パッケージまで自動で全部入るので本当に楽だnixは導入のハードルが高いと感じる一方で、miseはずっと実用的だ
Nixのやり方が重いと感じるなら、devenv.sh のようなツールでかなり入りやすくなる
たとえば
languages.rust.enable = trueですぐにrust開発環境を用意できるさらにスクリプト、タスク、パッケージも追加できる
設定例を共有してもらえるとありがたい
内容が興味深い
monorepoプロジェクトではjustとdocker(-compose)を使ってきたが、moonとprotoを少し試したときはやや期待外れだった
justのシンプルさは良いが、複数プラットフォームで新規メンバーをオンボーディングするときは、やはり手間が残る
自分もmiseで新しいプロジェクトをセットアップしてみた
新しく参加する人が手動の手順なしでずっとスムーズに始められるので本当に最高だ
miseでpostinstall hookを使うという話が興味深い
主に何を入れているのか知りたい
taskキャッシュをサポートしていない点はかなり大きな不満だ
タスクグラフに依存関係があるなら、すでに完了したタスクは再実行せずキャッシュで処理できるべきで、繰り返し実行の効率のために特に中規模のmonorepoでは重要だ
その機能の計画があるか調べたが、Miseのリポジトリではissueが無効化されており、READMEにも関連する記述がなく、あまり信頼できないと感じた
もしsingle-languageのnpm monorepoを使っているならWireitを勧める
Wireitはnpmスクリプトに依存関係とローカル/GitHub Actionsのキャッシュ機能を追加し、長時間動作するサービス型タスクも提供する
Wireit GitHub
MiseもMakeのようなタスクのローカルキャッシュはサポートしている
sourcesとoutputsを指定すれば可能で、mise task設定ガイドで確認できる
sourcesだけ指定してもsourceの変更は自動追跡される
この機能はdockerビルド高速化のためにかなり前に要望して、実際とても便利に使っている
むしろmiseがプロジェクトのソースコードやライブラリ依存関係にあまり踏み込まないのが、シンプルさの魅力だ
たいていはその境界までの機能だけを提供している
taskキャッシュはmiseの目指す方向とは異なる
anti-goals公式ドキュメントを参照
turbopack、moonrepoなどがすでにこの問題に注力している
miseは単にスクリプト実行に重点を置いた軽量タスクランナーのままでいる可能性が高い
Miseリポジトリのissueが閉じられている理由は自分にも分からない
以前は「maintainerはissuesよりdiscussionを好む」というissueがあったが、今は消えている
関連してこの議論を始めた
自分のように何年も使ってきた立場からすると、このプロジェクトへの信頼は大きく、周囲にも勧めている
discussionsと実際の利用経験を参考にしてみるといい
miseにビルドシステム（bazel系）の機能を求めるのに近い
すでにある意味ではそうした役割も果たしていると言えるかもしれない
キャッシュ機能は有用だが、機能追加で複雑さが増す可能性があるので慎重であるべきだ
既存のビルドシステムと連携する方法を考えるのもありだろう
miseはかなり良さそうだ
ただ、現在asdfユーザーの立場からすると、miseはさまざまなこと（PATH操作など）を少し過剰に管理しようとしているように見えて、ややためらいがある
複数のツールがそれぞれ違う形でPATHをいじるのが本当に面倒だったので、自分で .zprofile にPATHを固定し、各種初期化スクリプトも全部外してしまった
miseがプログラミング言語と、その言語からインストールされるCLIアプリ（cargo、go、uvなど）までまとめて管理してくれるなら良いが、そのあたりが移行時に少し面倒そうでもある
複数ツールがPATH優先順位をいじるのが不便だったと言っていたが、miseはそうはしない
望めばshimも使える
言語ごとのツールと、言語そのものの管理の両方をサポートしている
以前asdfからmiseに乗り換えた理由は正直あまり覚えていないが、何年も使っていて何の問題もなかった
miseは本当に最高だと思う
自動化や同一環境のセットアップ、新規プロジェクトの素早いブートストラップを重視する人にはぴったりだ
特にRuby/Python/Node環境で起こりがちな、各自のセットアップ方法の違いや、環境を繰り返し再現する問題を、Dockerのようなものなしでシンプルに解決してくれる
小さなチームや個人プロジェクトなら、CI環境やビルドシステム（Bazel、Gradleなど）がなくても、再現可能な実行環境を手軽に構築できる
chezmoiと組み合わせてローカルシステムのツール管理にも活用している
最近justからmiseに移行した
justも素晴らしいが、単なるコマンドランナー機能しか提供せず、自分にはmiseの追加機能が必要だった
移行して正解だったと思う
ただ、初心者にも分かりやすいように、ユースケース、歴史、他のツール（nix、dockerなど）との比較、構造的な説明がもっと充実しているとよい
実際の細かな違いを例で見ながら、なぜmiseが必要なのか、既存の他ツールと何が違うのかが、もう少し明確に文書化されてほしい
このニュースには本当に期待している
just/taskfileのようなシンプルなタスクランナーの長所と、bazel/buck2のような強力さをうまく組み合わせた感じがする
他の人がどう活用するのか気になるし、新しい試みとして楽しみだ
環境管理ワークフローはかなり簡素化された
ただtask runner機能は特に必要ない
Makeやjustでその役割は十分果たせる
実際にmonorepoで使ったことはないが、両ツールともtask/recipeファイルのimportや拡張をサポートしているので、必要に応じたセットアップは可能だと思う
UXは専用ツールほど滑らかではないかもしれないが、各ツールが単一の役割に集中しているほうが好みだ
miseはすでに環境マネージャーとして多くの機能を抱えているので、そちらに集中してくれると嬉しい
ちなみに相手はmiseの作者のようだ、感謝している
もしリポジトリのタスクを単一のエントリポイントで管理したいなら、自分が作った dela も検討に値する
pyproject.toml、package.json、makefile など多様なタスクファイル定義をスキャンし、タスク名でそのままCLIから実行できるようにしてくれる
複数のリポジトリで追加の改善なしにそのまま使えて非常に便利だったし、リポジトリ構造を変えなくていいのも利点だ
まだmiseのtaskはサポートしていないが、需要があればすぐ追加するつもりだ
最近の集計によると、miseはスター数の多いGitHubリポジトリ10万件のうち94件で使われている
詳細なデータは 2025 task runners census を参照してほしい
Nodeプロジェクトのリポジトリに入ると、いつも最初に
npm runでスクリプト一覧を確認するMakefileがあれば中を見るが、ターゲットや依存関係が全部変数になっていると、その時点で閉じてしまう
ちょうどmiseにもこういう機能があればいいのにと思っていたところに新しく出てきてうれしい
miseを使っていて一番良かったのは、npm、go、cargo などを通じてバックエンドでグローバルツールをインストールできる機能だ
たとえば
mise use -g npm:prettierのようなシンプルなコマンドで簡単に入れられる昔はnvmを使うたびに、どのnodeバージョンにグローバルパッケージを入れたのかをいつも覚えていなければならなかったが、miseのおかげでずっと楽になった
ただ最近、nodeの最新バージョンを入れようとしたら、2番目に新しいバージョンが入るという小さなバグがあった
pure Nix-shellが使えるなら、miseの魅力は少し下がるかもしれない
それでもNixより学習曲線が低いので、もっと広く普及する可能性はありそうだ
自分や自分のPCだけでなく、さまざまな人がプロジェクトを簡単にブートストラップできることに特化しているという観点で、miseは本当に際立っている
tomlベースの設定も、人が理解するにはとてもシンプルだ
昔のようにREADMEを掘り返して手動で環境を合わせたり、言語ごとに導入方法が違って面倒だったりすることが、miseでは問題にならない
Node/Ruby/Python系の環境を管理するときには特に有利だ
nix-darwinを1年間使ってみて、結局miseに乗り換えた
miseは必要な機能の90%を、1%の手間で満たしてくれる
nixの考え方も良いし、将来のソフトウェアビルドのあり方は確かにこういう流れに向かうと思う
ただ、少なくとも今その担い手がnixであるとは限らないと思う