Mise: Pengenalan fitur Task Monorepo

 (github.com/jdx)
7 poin oleh GN⁺ 2025-10-07 | 2 komentar | Bagikan ke WhatsApp
  • mise mengumumkan fitur task monorepo baru
  • Menyediakan namespace task terpadu yang memudahkan pengelolaan environment, tool, dan task untuk masing-masing proyek dalam repositori besar
  • Mencakup berbagai fitur seperti pola wildcard yang kuat, pewarisan environment/tool, dan konteks eksekusi yang konsisten
  • Memberikan kesederhanaan dan fleksibilitas untuk monorepo dengan berbagai bahasa atau environment yang kompleks
  • Dibandingkan Bazel, Turborepo, dan lainnya, keunggulannya adalah agnostik bahasa, konfigurasi mudah, dan pengelolaan terpadu

Pengenalan: pengumuman fitur task monorepo

  • mise memperkenalkan fitur baru bernama Monorepo Tasks
  • Menyediakan dukungan monorepo kelas satu agar tool, variabel environment, dan task untuk tiap proyek di dalam repositori yang berisi banyak proyek dapat dipertahankan secara terpisah dan dikelola dengan efisien

Fitur utama

  • Namespace task terpadu: secara otomatis menemukan semua task dalam monorepo, lalu memberi prefiks berdasarkan lokasi agar dapat dibedakan dengan jelas
    Contoh:
    mise //projects/frontend:build
    mise //services/api:deploy
  • Pewarisan tool dan environment yang cerdas: mendefinisikan tool bersama di root, lalu menimpanya di subproyek bila diperlukan
    • Contoh: pengaturan node=20, python=3.12 di mise.toml root otomatis diwariskan ke semua subproyek
    • Di proyek tertentu (mise.toml), node=14 bisa digunakan sebagai override, sementara pengaturan python dari level atas tetap diwariskan
  • Pola wildcard yang kuat:
    • Menjalankan test untuk semua proyek: mise //...:test
    • Menjalankan semua build di bawah services/: mise //services/...:build
    • Menjalankan semua task di dalam frontend: mise '//projects/frontend:*'
    • Memungkinkan eksekusi grup berdasarkan nama task
  • Eksekusi yang konsisten kapan pun: di mana pun task dijalankan, task tersebut tetap berjalan dengan environment dan tool sebagaimana didefinisikan di config_root task itu
  • Propagasi trust otomatis: cukup mendaftarkan trust pada root monorepo, lalu konfigurasi turunannya akan otomatis dipercaya

Panduan mulai cepat

  1. Atur experimental_monorepo_root=true di mise.toml root
  2. Aktifkan flag eksperimen (MISE_EXPERIMENTAL=1)
  3. Tambahkan tasks ke mise.toml tiap proyek
    • Contoh:
      [tasks.build]
      run = "npm run build"
  4. Jalankan task yang diinginkan dari root maupun dari path mana pun
    • mise //projects/frontend:build
    • mise //...:test

Contoh struktur monorepo

  • myproject/
    ├── mise.toml (experimental_monorepo_root = true)
    ├── services/
    │ ├── api/mise.toml
    │ ├── worker/mise.toml
    │ └── scheduler/mise.toml
    └── apps/
    ├── web/mise.toml
    └── mobile/mise.toml
  • Menjalankan build untuk semua service: mise //services/...:build
  • Menjalankan test untuk semua aplikasi: mise //apps/...:test
  • Semua task: mise '//...:*'

Latar belakang dan dampak

  • Berangkat dari persoalan kompleksitas pengelolaan monorepo dan script yang berulang
  • Mendefinisikan sekali, menjalankan dari mana saja untuk meminimalkan duplikasi
  • Penerapan tool/environment yang tepat secara otomatis untuk tiap proyek
  • Penyederhanaan pipeline CI/CD dengan wildcard yang kuat
  • Namespace task meningkatkan kemudahan penelusuran dan pemahaman

Perbandingan dengan tool utama yang ada

  • Simple Task Runners (Taskfile, Just, dll.)

    • Optimal untuk otomatisasi satu proyek, tetapi di monorepo tidak mendukung namespace terpadu, pewarisan, maupun wildcard
    • mise menawarkan penemuan task otomatis dan dukungan pola yang kuat

  • Tool berfokus JavaScript (Nx, Turborepo, Lerna)

    • Kuat untuk monorepo JS/TS (dependency graph, codegen, cache, dll.)
    • mise agnostik bahasa, mendukung beragam bahasa/stack, serta pengelolaan tool dan variabel environment secara terpadu

  • Sistem build skala besar (Bazel, Buck2)

    • Menyediakan distributed cache, remote execution, dan lainnya, tetapi kompleksitas serta kurva belajarnya tinggi dan banyak batasan struktur
    • mise mengambil pendekatan non-hermetic, dengan konfigurasi yang fleksibel dan adopsi yang mudah

  • Lainnya (Rush, Moon, dll.)

    • Rush: orkestrasi build khusus JS
    • Moon: berbasis Rust, berorientasi pada dukungan multi-bahasa

Keistimewaan Monorepo Tasks di mise

Fitur Simple Runners Khusus JS Build Systems mise
Dukungan multi-bahasa ✅ ❌ ✅ ✅
Mudah dipelajari ✅ ⚠️ ❌ ✅
Penemuan task terpadu ❌ ✅ ✅ ✅
Pola wildcard ❌ ⚠️ ✅ ✅
Manajemen versi tool ❌ ❌ ⚠️ ✅
Pewarisan environment ❌ ⚠️ ❌ ✅
Konfigurasi minimal ✅ ⚠️ ❌ ✅
Caching task ❌ ✅ ✅ ❌
  • Kapan memilih Mise?
    • Monorepo multi-bahasa
    • Pengelolaan tool dan task terpadu
    • Jika lebih menyukai kesederhanaan
    • Cocok bagi pengguna yang sudah familiar dengan mise
  • Kapan sebaiknya mempertimbangkan yang lain
    • Fokus hanya pada JS/TS → Nx, Turborepo
    • Enterprise berskala sangat besar (Google/Meta, dll.) → Bazel, Buck2
    • Membutuhkan caching task tingkat lanjut → Nx, Turborepo, Bazel

Kesimpulan

  • Fitur task monorepo di mise dirancang agar monorepo kompleks dengan berbagai bahasa tidak terbatas pada satu bahasa saja, sehingga dapat dikelola dengan mudah dan konsisten
  • Dengan konfigurasi minimal dan pola task yang kuat, fitur ini meningkatkan produktivitas sekaligus pengalaman pengembang
  • Jauh lebih ringkas dan fleksibel dibanding solusi enterprise yang kompleks

Bacaan terkait

2 komentar

 
GN⁺ 2025-10-07
Opini Hacker News

  • Saat dulu lebih banyak memakai Python, saya tidak terlalu merasakan daya tarik Mise; rasanya uv sudah cukup.
    Tetapi ketika perlu menyesuaikan versi per direktori seperti di Node, dan membutuhkan entry point umum seperti mise build atau mise test tanpa peduli bahasa atau jenis proyek, di situlah keunggulan Mise benar-benar terasa.
    Saya juga sangat menyukai Just sebagai runner untuk task, dan berkat itu saya bisa lepas dari Make.
    Make memang kuat, tetapi ada beberapa hal yang kurang dari sisi pengalaman pengembang.
    Mungkin Just secara fitur lebih kuat daripada fitur task di Mise, tetapi bagi saya Mise adalah kombinasi terbaik karena punya fitur task yang cukup bagus sekaligus manajemen tool yang luar biasa

    • Sebagai penggemar Makefile sederhana, saya penasaran keuntungan apa yang Anda rasakan saat berpindah dari Make ke Just lalu ke Mise.

    • Saya benar-benar suka just, tetapi di just task menyiapkan environment yang tepat cukup merepotkan, dan memuat virtual environment juga terasa ribet.
      Jadi saya beralih ke mise dengan alasan yang mirip.

  • Saya sangat antusias dengan mise.
    Setiap kali memulai proyek baru, alat ini cepat menjadi tool wajib.
    Sangat praktis karena dengan satu file konfigurasi saya bisa sekaligus mengelola berbagai tool seperti node, python, rust, go, dan juga punya pengganti makefile yang mudah dipakai.
    Biasanya saya menyiapkan hook postinstall, jadi ketika seseorang mengambil proyek saya, cukup menjalankan mise install dan versi tool yang tepat beserta paket dependensinya akan terpasang otomatis.
    Dibandingkan nix yang terasa punya hambatan masuk tinggi, mise jauh lebih praktis.

    • Jika pendekatan Nix terasa membebani, tool seperti devenv.sh bisa sangat meningkatkan aksesibilitas.
      Misalnya, Anda bisa langsung menyiapkan environment pengembangan rust dengan languages.rust.enable = true.
      Selain itu, Anda juga bisa menambahkan skrip, task, dan paket.

    • Saya penasaran apakah Anda bisa membagikan contoh konfigurasinya.
      Isinya terdengar menarik.
      Selama ini saya memakai just dan docker(-compose) untuk proyek monorepo, dan pengalaman mencoba moon & proto hanya sebentar serta agak mengecewakan.
      Kesederhanaan just memang bagus, tetapi onboarding anggota baru di berbagai platform tetap merepotkan.

    • Saya juga menyiapkan proyek baru dengan mise.
      Ini benar-benar luar biasa karena orang baru bisa mulai jauh lebih mudah tanpa langkah manual.

    • Menarik juga melihat penggunaan hook postinstall di mise.
      Saya penasaran biasanya Anda memasukkan apa di sana.

  • Tidak adanya dukungan cache task adalah kekurangan yang cukup besar.
    Ketika ada dependensi dalam grafik pekerjaan, task yang sudah selesai seharusnya diproses lewat cache tanpa dijalankan ulang agar eksekusi berulang efisien, terutama di monorepo ukuran menengah.
    Saya mencoba mencari apakah fitur itu direncanakan, tetapi issue di repositori Mise dinonaktifkan dan README juga tidak menyebutkannya, jadi rasanya kurang meyakinkan.
    Jika Anda memakai monorepo npm satu bahasa, saya merekomendasikan Wireit.
    Wireit menambahkan dependensi serta cache lokal/GitHub Actions ke skrip npm, dan menyediakan task tipe service yang berjalan lama.
    Wireit GitHub

    • Mise juga mendukung cache lokal untuk task seperti Make.
      Ini bisa dilakukan dengan menentukan sources dan outputs; lihat panduan konfigurasi task mise.
      Bahkan jika hanya menentukan sources, perubahan source tetap akan dilacak otomatis.
      Fitur ini sudah lama saya minta untuk mempercepat build docker, dan saya memakainya dengan sangat berguna.

    • Justru kesederhanaannya menarik karena mise tidak terlalu peduli pada source code proyek atau dependensi library.
      Biasanya fiturnya hanya disediakan sampai batas itu.

    • Caching task memang bukan arah yang dituju mise.
      Lihat dokumen resmi anti-goals.
      turbopack, moonrepo, dan lainnya sudah berfokus pada masalah itu.
      Besar kemungkinan mise akan tetap menjadi task runner ringan yang berfokus hanya pada eksekusi skrip.

    • Saya juga tidak tahu kenapa issue di repositori Mise dimatikan.
      Dulu pernah ada issue yang mengatakan "maintainer lebih memilih discussion daripada issues", tetapi sekarang sudah hilang.
      Saya memulai diskusi ini terkait hal tersebut.
      Dari sudut pandang saya yang sudah memakainya beberapa tahun, saya sangat percaya pada proyek ini dan merekomendasikannya ke sekitar saya.
      Saya sarankan melihat discussions dan pengalaman penggunaan nyata.

    • Ini mirip seperti meminta fitur sistem build ala bazel ke mise.
      Mungkin saat ini pun ia sudah sedikit memainkan peran itu.
      Fitur cache memang berguna, tetapi harus hati-hati karena penambahan fitur bisa menambah kompleksitas.
      Mungkin juga layak dipikirkan cara integrasi dengan sistem build yang sudah ada.

  • mise terlihat cukup bagus.
    Hanya saja, sebagai pengguna asdf saat ini, saya agak ragu karena mise tampak ingin mengelola terlalu banyak hal, seperti manipulasi PATH.
    Sangat merepotkan ketika banyak tool masing-masing mengutak-atik PATH, jadi saya akhirnya menetapkan PATH langsung di .zprofile dan membuang semua skrip inisialisasi.
    Akan bagus jika mise bisa sekaligus mengelola bahasa pemrograman dan aplikasi CLI yang dipasang dari bahasa tersebut (cargo, go, uv, dan sebagainya), tetapi bagian itu juga terasa agak merepotkan saat migrasi.

    • Anda bilang tidak suka ketika banyak tool memanipulasi prioritas PATH, tetapi mise tidak bekerja seperti itu.
      Kalau mau, Anda juga bisa memakai shim.
      Pengelolaan tool per bahasa dan bahasa itu sendiri sama-sama didukung.

    • Saya tidak terlalu ingat kenapa dulu berpindah dari asdf ke mise, tetapi setelah memakainya selama beberapa tahun, saya tidak pernah mengalami masalah.

  • Saya benar-benar menganggap mise luar biasa.
    Ini sangat cocok untuk orang yang serius soal otomasi, penyetelan environment yang konsisten, dan bootstrap proyek baru dengan cepat.
    Khususnya di lingkungan Ruby/Python/Node, ia menyelesaikan masalah perbedaan cara setup masing-masing dan reproduksi environment berulang tanpa perlu sesuatu seperti Docker.
    Di tim kecil atau proyek pribadi, ini memungkinkan pembangunan environment yang bisa diulang dengan mudah tanpa perlu environment CI atau sistem build seperti Bazel, Gradle, dan sebagainya.
    Saya juga memakainya bersama chezmoi untuk mengelola tool sistem lokal.

  • Saya baru-baru ini pindah dari just ke mise.
    just juga sangat bagus, tetapi ia hanya menyediakan fungsi runner perintah, sedangkan saya membutuhkan fitur tambahan yang dimiliki mise.
    Saya merasa keputusan pindah itu tepat.
    Namun akan lebih baik jika ada penjelasan yang lebih terstruktur dan mudah dipahami pemula tentang use case, riwayat, perbandingan dengan tool lain (nix, docker, dll.), dan arsitekturnya.
    Saya berharap dokumentasinya menjelaskan dengan lebih jelas “mengapa” mise dibutuhkan dan apa pembedaannya dari tool lain yang sudah ada, mungkin lewat contoh yang menunjukkan perbedaan-perbedaan kecil secara nyata.

  • Saya sangat antusias dengan kabar ini.
    Rasanya seperti perpaduan yang pas antara kelebihan task runner sederhana seperti just/taskfile dan kekuatan tool seperti bazel/buck2.
    Saya penasaran bagaimana orang lain akan memakainya, dan saya menantikan percobaan baru ini.

    • Saya juga terutama memakai mise dan hampir sepenuhnya puas.
      Workflow manajemen environment saya jadi jauh lebih sederhana.
      Namun saya sebenarnya tidak merasa butuh fitur task runner.
      Make atau just sudah cukup menjalankan peran itu.
      Saya memang belum memakainya di monorepo, tetapi kedua tool itu mendukung import dan perluasan file task/resep, jadi menurut saya setup bisa disesuaikan sesuai kebutuhan.
      Mungkin UX-nya tidak semulus tool yang dibuat khusus untuk itu, tetapi saya lebih suka tiap alat fokus pada satu peran.
      mise sendiri sudah memuat cukup banyak fungsi sebagai manajer environment, jadi saya berharap ia fokus ke sana.
      Oh ya, sepertinya lawan bicara saya adalah penulis mise, terima kasih.

  • Jika Anda ingin mengelola task repositori dengan satu entry point, mungkin layak mempertimbangkan dela yang saya buat.
    Tool ini memindai berbagai definisi file task seperti pyproject.toml, package.json, makefile, dan lainnya, lalu memungkinkan task dijalankan langsung dari CLI berdasarkan nama task.
    Ini sangat praktis karena bisa langsung saya pakai di banyak repo tanpa modifikasi, dan kelebihannya juga tidak perlu mengubah struktur repo.
    Saat ini belum mendukung task mise, tetapi jika ada kebutuhan saya siap menambahkannya.
    Menurut rekap terbaru, mise dipakai di 94 dari 100 ribu repositori GitHub berbintang tinggi.
    Untuk data lebih lengkap, lihat 2025 task runners census

    • Kelihatannya keren, apakah juga mendukung daftar lengkap semua task?
      Saat masuk ke repo proyek Node, hal pertama yang selalu saya lakukan adalah menjalankan npm run untuk melihat daftar skrip.
      Kalau ada Makefile, saya juga akan membukanya, tetapi jika target atau dependensinya semuanya ditulis sebagai variabel, saya biasanya langsung menyerah.

  • Kebetulan saya juga sedang berpikir akan bagus kalau mise punya fitur seperti ini, jadi senang melihat ini baru dirilis.
    Hal yang paling saya sukai dari mise saat memakainya adalah kemampuan untuk memasang tool global di backend seperti npm, go, cargo, dan sebagainya.
    Misalnya, sangat mudah dipasang dengan perintah sederhana seperti mise use -g npm:prettier.
    Dulu saat memakai nvm, saya harus selalu mengingat paket global itu dipasang di versi node yang mana, tetapi berkat mise semuanya jadi jauh lebih nyaman.
    Hanya saja, baru-baru ini saat mencoba memasang versi terbaru node, ada bug kecil yang malah memasang versi terbaru kedua.

  • Jika Anda bisa memakai pure Nix-shell, daya tarik mise mungkin sedikit berkurang.
    Meski begitu, karena kurva belajarnya lebih rendah daripada Nix, saya rasa ia bisa menyebar lebih luas.

    • mise benar-benar menonjol jika dilihat dari sudut pandang memudahkan banyak orang, bukan hanya diri sendiri atau PC sendiri, untuk melakukan bootstrap proyek.
      Konfigurasi berbasis toml juga sangat sederhana untuk dipahami orang.
      Hal-hal yang dulu merepotkan seperti membongkar README lama untuk menyesuaikan environment secara manual, atau metode instalasi yang berbeda untuk tiap bahasa, tidak lagi menjadi masalah di mise.
      Ini sangat menguntungkan terutama saat mengelola environment Node/Ruby/Python.

    • Saya memakai nix-darwin selama setahun lalu akhirnya pindah ke mise.
      mise memenuhi 90% dari kebutuhan saya hanya dengan 1% kerepotan.
      Saya juga suka konsep nix, dan saya yakin masa depan cara membangun software memang akan bergerak ke arah seperti itu.
      Hanya saja, untuk saat ini saya merasa pelaku utamanya mungkin bukan nix.