ハクソク

世界を動かす技術を、日本語で。

Mise: モノレポタスク

231日前原文(github.com)

概要

mise に Monorepo Tasks が登場。 複数プロジェクトを単一リポジトリで 効率管理 可能。 タスク自動検出 ・ ツール継承 ・ ワイルドカード実行 を提供。 多言語対応 ・ シンプルな設定 で大規模モノレポもサポート。 既存のツールと比較しつつ、 導入メリット を解説。

Monorepo Tasks 新機能発表

  • Monorepo Tasks は、複数プロジェクトを1つのリポジトリで管理するための 新機能。
  • 各プロジェクトごとに 独立したツール・環境変数・タスク を維持可能。
  • Bazel や Turborepo のような強力なモノレポ管理機能を、 mise流のシンプルさ で実現。
  • 全タスクの自動検出 と 名前空間付与 により、識別性と実行管理性を向上。
    • 例：mise //projects/frontend:build や mise //services/api:deploy 形式で実行。

主な特徴

  • 統一タスク名前空間 ：全プロジェクトのタスクを自動検出し、パスでプレフィックス付与。
  • スマートなツール・環境継承 ：ルートで共通ツール定義、プロジェクトごとに上書き可能。
    • 例：node = "20"（全体）、node = "14"（特定プロジェクトのみ上書き）
  • 強力なワイルドカードパターン ：複数プロジェクトのタスクを一括実行。
    • 例：mise //...:test や mise '//projects/frontend:*'
  • どこからでも一貫実行 ：リポジトリ内のどこからでも、正しいツール・環境でタスク実行。
  • 自動信頼伝播 ：ルートを一度信頼すれば、配下の設定も自動で信頼。

クイックスタート

  • ルートmise.tomlで 機能有効化 ：experimental_monorepo_root = true

  • 環境変数セット ：export MISE_EXPERIMENTAL=1

  • 各プロジェクトに タスク追加 ：[tasks.build] run = "npm run build"

  • どこからでもタスク実行 ：mise //projects/frontend:build や mise //...:test

    • 例：
      • サービス全ビルド：mise //services/...:build
      • アプリ全テスト：mise //apps/...:test
      • 全タスク一括：mise '//...:*'

導入メリット

  • スクリプト重複排除 ：一度定義すればどこからでも使える。
  • 一貫した環境提供 ：各プロジェクトに必要なツールを正確に割り当て。
  • 自動化容易 ：ワイルドカードでCI/CDパイプラインも簡単。
  • 開発体験向上 ：明確で発見しやすいタスク名前空間。

他ツールとの比較

  • Taskfile/Just （シンプルなタスクリーダー）
    • 単一プロジェクト向け。モノレポ向けの自動検出や継承機能は非搭載。
    • miseの強み ：モノレポ全体での自動タスク検出・ワイルドカードパターン。
  • Nx/Turborepo/Lerna （JavaScript特化）
    • JS/TSモノレポに特化。依存グラフやキャッシュなど強力だが、他言語対応は限定的。
    • miseの強み ：多言語対応、ツールバージョン管理、環境変数一元化。
  • Bazel/Buck2 （大規模ビルドシステム）
    • 超大規模向け。厳格な分離や複雑なDSLが必要で、学習コスト・運用コスト大。
    • miseの強み ：非エルメティック（柔軟運用）、TOMLで簡単設定、既存コードベースの大幅変更不要。
  • Rush/Moon （その他注目ツール）
    • RushはJS依存管理特化、MoonはRustベースで多言語対応志向。

miseのスイートスポット

| 機能 | シンプルランナー | JS特化ビルド | mise | |--------------------------|------------------|--------------|------| | 多言語対応 | ✅ | ❌ | ✅ | | 学習コスト小 | ✅ | ⚠️ | ✅ | | タスク自動検出 | ❌ | ✅ | ✅ | | ワイルドカードパターン | ❌ | ⚠️ | ✅ | | ツールバージョン管理 | ❌ | ❌ | ✅ | | 環境継承 | ❌ | ⚠️ | ✅ | | 最小構成 | ✅ | ⚠️ | ✅ | | タスクキャッシュ | ❌ | ✅ | ❌ |

miseが最適なケース

  • 多言語モノレポ 運用
  • ツール＋タスク一元管理 を求める場合
  • シンプルさ重視 かつ十分なパワーが欲しい場合
  • 既にmiseでツール管理 している場合

他ツールを検討すべきケース

  • JS/TS専用 ：NxやTurborepoがより多機能
  • Google/Meta級の大規模 ：Bazel/Buck2が分散ビルドに最適
  • 高度なタスクキャッシュ必須 ：Nx、Turborepo、Bazelを推奨

まとめ・フィードバック募集

  • Monorepo Tasks は実験的機能だが、 即利用可能 で十分な完成度。
  • API変更の可能性あり、ユーザーからの フィードバック歓迎。
  • 公式ドキュメント ：「Monorepo Tasks Guide」も参照推奨。
  • 利用体験や要望、改善点など コミュニティで共有 を呼びかけ。
  • miseコミュニティへの感謝 と今後の発展への期待。

Hackerたちの意見

これめっちゃ楽しみ！シンプルなタスクランナーのjust/taskfileと、bazel/buck2みたいな強力なツールの両方の良さを兼ね備えてると思う。みんなが何を作るのか、すごく楽しみだな！

└

うーん、どうしようか迷ってる。miseは使ってて、だいたい好きなんだけど。環境管理のワークフローが簡素化されたのはいいけど、タスクランナーは必要ないんだ。Makeとjustがその役割を果たしてるから。モノレポでは使ったことないけど、どちらもタスク/レシピファイルのインポートや拡張をサポートしてるから、適切に設定するのは可能だと思う。もしかしたら、その用途に特化したツールほどUXは洗練されてないかもしれないけど、私はツールには「一つのことを上手くやってほしい」んだ。miseはすでに環境管理としてかなりのことをやってるから、そういう問題に集中してほしいな。あ、あなたが作者なんだね。すべての作業に感謝！

ずっと同じRust CLIタスクのセットを集めてたんだけど、これをcargo-generateのテンプレートジェネレーターとして使ってたんだ。最近、Rustサーバー、Svelteフロントエンド、Terraformデプロイメントが混在するモノレポを書いてた時に問題が出てきた。これを使うタイミングがちょうど良くて、頭がおかしくならずに済みそう。あと、lernaを含む他のビルダーやマネージャーとの相性があまり良くなかったから、これが好きなんだ。@jdxcode、Emacsをmiseに置き換えられるのはいつ？

└

絶対に置き換えたくない！スコープが十分大きいから！

miseはツールとしてすごく期待してる。新しいプロジェクトを始める時の定番ツールの一つになった。ツール（node、python、rust、goなど）を管理するための設定ファイルが一つで済むのがめっちゃ便利だし、シンプルなmakefileの代替にもなる。ほぼ毎回postinstallフックを設定してるから、誰かが私のプロジェクトのmise installを実行すれば、正しいツールのバージョンがインストールされて、依存関係も自動的にインストールされる（npm installを実行するみたいに）。nixみたいに習得が難しい感じじゃなくて、かなり実用的だと思う。

└

miseのpostinstallフックって何を入れるの？

└

そうそう！miseで新しいプロジェクトを立ち上げたんだ。新しい人が始めるのがすごく楽になるし、手動のステップがいらないのがいいね。素晴らしいツールだよ。

└

Nixの使い方をもっと身近にしてくれるツールがあるよ：https://devenv.sh/ 例えば、languages.rust.enable = trueって書くだけで、すぐに始められる。スクリプトやタスク、他のパッケージも追加できるし。

miseに乗り遅れたのは、理解するのに時間がかかったから（多分、direnvの代替としてもっと機能があると思ってたから）。特に企業の厳しい環境での生活が楽になるよ（人によるけど）。

└

こういう意見を聞けて嬉しいな…最初に見たとき、Windowsがサポートされてるのに気づかなかったし、dotnetのサポートもあるみたいだね…だから近いうちに試してみようかな。俺の作業環境は結構制限されてるし…仕事とプライベートで一貫性があるから、主にDeno+TSを使ってシェルスクリプトを書いてるんだ。ツール自体を仕事のプロジェクトで管理するためには使ってないけどね。

これ、moonと比べてどうなの？ https://github.com/moonrepo/moon

└

moonにはあまり詳しくないけど、miseはツールの問題を解決するところから始まったのに対して、moonはビルドの問題を先に解決したって言えると思う。両者とも、その分野ではどちらかがより充実してるんじゃないかな。もしかしたら、moonのビルドにmiseのツールを使ったり、miseのタスクでprotoを使ったりもできるかもね。

Bazelとmiseの両方の経験がある人、miseがBazelとアナーキーの間の「スイートスポット」を実現してるかどうかコメントしてくれない？私はBazelをたくさん使って貢献もしてるけど、エンジニアリングチームが採用するのは難しいかもしれないと思ってる。

└

bazelを約10年間、小さな組織で使ってきたよ。今はチームが一桁。JavaとC/C++を混ぜたプロジェクトには、Bazelより良い解決策はないと思う。bazelの新しいモジュールシステムはかなり成熟してきたね。例えば、boringsslを追加してJavaからアクセスするのは簡単だよ。

タスクのキャッシングがないのは、かなり大きな欠点だね。依存関係のあるタスクのグラフを描けるようになったら、すでにクリーンな依存関係を実行しないのが、モデレートサイズのモノレポでも繰り返し実行可能にする方法なんだ。計画してるかどうかを確認するために問題を探したけど、Miseのリポジトリにはイシューが有効になってない？READMEにもその理由についての議論がないし、それは信頼感を欠くよね。もし単一言語のnpmモノレポにいるなら、Wireitをチェックしてみて。普通のnpmスクリプトを拡張して、依存関係やキャッシング（ローカルとGitHubアクション）を持てるようにしてる。長時間実行するタスク用のユニークなサービスタイプのスクリプトもあって、依存関係を再構築したり、サービスを再起動せずに済むんだ。 https://github.com/google/wireit/

└

miseがプロジェクトのソースコードやライブラリの依存関係に無関心なところが、使う価値のあるシンプルさを生んでると思う。例外もいくつかあるけど、一般的にはそこがmiseの限界かな。

└

問題があるか見に行ったけど、Miseのリポジトリにはイシューが有効になってないの？ READMEにもその理由についての議論がないし。それはちょっと信頼感を欠くね。イシューがオフになったのはいつ/なぜか分からないけど、それは…驚きだね。以前は、メンテナがイシューよりも議論を好むっていうイシューがあったんだけど、今は404になってる。イシューがないことについて議論を始めたよ: https://github.com/jdx/mise/discussions/6566 信頼感について言うと、私はこのプロジェクトを数年使ってきたから、かなり信頼してるし、みんなに勧めてるよ。議論をイシューより好むのは珍しいけど、miseのリリース頻度と実用性は自分で証明してるから。議論を見て回ったり、ただ使ってみたりする時間を取ってみてね。 :)

└

あなたはmiseをbazelのようなビルドシステムにしようとしてるんですね。ある意味では、もうそうなってるかもしれません。キャッシングは便利な機能ですが、miseは複雑さが増すのを防がないといけませんね。ビルドツールとの統合も考えられるかも。

└

キャッシングタスクは逆に目指すべきじゃないことが分かりましたね。https://mise.jdx.dev/roadmap.html#anti-goals > リモートタスクキャッシング - turbopackやmoonrepoなど、多くのツールがこの（大きな）問題を解決しようとしています。miseのタスクランナーは、スクリプトを実行するためのシンプルな便利機能であり続けるでしょう。

└

miseは、ソースと出力を指定すればローカル専用のMakeに似たタスクキャッシングを行いますよ。https://mise.jdx.dev/tasks/task-configuration.html#sources ソースを指定しても「出力」を指定しなければ、miseはソースが変更されたかどうかを自動で追跡します。Dockerビルドを早くするためにこの自動追跡機能をリクエストしたのはかなり前ですが、素晴らしい結果が得られました。

└

タスクキャッシングの話をすると、Mint/RWXは本当に素晴らしいことをやってますよね。依存関係のグラフを作って、実行した後に変更されたものだけを実行するっていうのが、まさにその通りです。CI/CDタスクのスピードアップとコスト削減に本当に役立ちます。

これ、めっちゃ素晴らしい！ありがとう！Pythonを主に使ってた時は、Miseのことがあんまり「わからなかった」んだ。あ、uvがあるからね！でも、Nodeみたいに各ディレクトリで特定のバージョンを使いたい時や、言語に関係なくmise buildやmise testみたいな共通のエントリーポイントが欲しい時には、本当に輝くんだよね。誤解しないでほしいけど、Justもタスクランナーとして大好きだよ。Makeから乗り換えたのもこれのおかげで、Makeはすごくパワフルだけど、DevExの面ではちょっと物足りないところがあるからね。多分、Miseのタスクよりも「パワフル」だと思う。でも、Miseの優れたタスクランナーとツール管理の組み合わせは、私が扱うものには最強だよ。

└

単純なMakefileが好きな私としては、MakeからJust、そしてMiseに移行してどんな利点があったのかちょっと気になります。

└

そうですね、Justは大好きですが、Justタスクで正しい環境を整えるのが面倒なこともあります。仮想環境を読み込むのもイライラしますし。この理由でmiseに切り替えました。

Nix-shellを使えるのに、Miseを勧めるのは難しいな。でも、Nixよりも学習コストが低いから、もっと広まる可能性はあると思う。

miseはかなりクールに見えますが、今（現在のasdfユーザー）参加するのに躊躇している理由は、管理しようとしすぎているように感じるからです。特にPATHの操作に関して。複数のツールが私のPATHを勝手に書き換えようとして、いつも自分たちを最初に持ってこようとするのにはかなりイライラしました。最終的には、.zprofileにPATHをハードコーディングして、いろんなツールの初期化スクリプトを排除することに決めました。そうすれば、どの順番で何があるのかをはっきり見てコントロールできるし、微妙に異なるアルゴリズムで書き換えようとするスクリプトがたくさんあるのを避けられます。もしmiseが「ツール」（いろんなプログラミング言語）と「ツール」（その言語のマネージャーで通常インストールされるCLIアプリケーション）を管理できるなら、うまくいくかもしれませんが、そうなると切り替えが面倒になりそうです。

└

複数のツールが私のPATHを勝手に書き換えようとして、いつも自分たちを最初に持ってこようとするのにはかなりイライラしました。これをやらないし、本当に必要ならmiseでシムを使うこともできますよ。 > もしmiseが「ツール」（いろんなプログラミング言語）と「ツール」（その言語のマネージャーで通常インストールされるCLIアプリケーション）を管理できるなら、うまくいくかもしれませんが、そうなると切り替えが面倒になりそうです。これをやってますよ。

└

なんでasdfからmiseに切り替えたのかは覚えてないけど、ここ数年は特に問題なかったよ。