Mise vs SDKMAN: Proč přecházím po letech s .sdkmanrc

Kolega dnes zmínil Mise. Jsem věrný uživatel SDKMAN už roky — .sdkmanrc v každém projektu, sdk use java 21.0.2-tem vrytý do svalové paměti. Funguje to, je to spolehlivé, nikdy jsem neměl důvod hledat jinde.

Pak jsem se ale podíval, co Mise umí, a nejsem si jistý, jestli se můžu vrátit.

Problém s jedním nástrojem na jazyk

SDKMAN spravuje JDK (a Gradle, Maven a pár dalších JVM nástrojů). Dělá to dobře. Ale moje projekty nepotřebují jen Javu:

• Java 21 (Temurin)
• Node 22 (pro frontend build)
• Terraform (pro infrastrukturu)
• Python 3.12 (pro skripty)

Takže mám SDKMAN na Javu, nvm na Node, pyenv na Python a tfenv na Terraform. Každý má svůj konfigurák, své shell hooky, svůj způsob pinování verzí. Můj .zshrc načítá čtyři správce verzí, každý přidává latenci při každém novém shellu.

Mise je všechny nahradí jedním nástrojem a jedním konfigurákem:

# .mise.toml
[tools]
java = "temurin-21"
node = "22"
python = "3.12"
terraform = "1.9"

To je vše. Jeden soubor v kořenu repozitáře. Všichni v týmu dostanou stejné verze. Žádné “u mě to funguje”, protože někdo zapomněl spustit sdk install.

Co Mise dělá lépe

Rychlost

SDKMAN používá shell skripty. Každý nový terminál načítá inicializační skript SDKMAN, který přidává znatelnou latenci. Mise je napsaný v Rustu a modifikuje PATH přímo místo používání shimů. Režie je ~5ms při startu shellu vs. ~120ms u nástrojů založených na shimech jako asdf. SDKMAN je někde mezi, ale není v lize Mise.

Jeden konfigurak pro všechno

Místo .sdkmanrc + .nvmrc + .python-version + .terraform-version máte jediný .mise.toml. Podporuje všech 500+ nástrojů z ekosystému asdf pluginů, plus vlastní kurátované backendy.

Proměnné prostředí

Mise funguje zároveň jako náhrada direnv. Můžete nastavit projektově specifické proměnné prostředí ve stejném konfiguráku:

[tools]
java = "temurin-21"

[env]
SPRING_PROFILES_ACTIVE = "local"
DATABASE_URL = "jdbc:postgresql://localhost:5432/myapp"

Žádné .env soubory, které se náhodou commitnou.

Tasky

Mise může nahradit i make a npm skripty:

[tasks.dev]
run = "java -jar build/libs/app.jar"
depends = ["build"]

[tasks.build]
run = "./gradlew build -x test"

mise run dev   # nejdřív buildne, pak spustí

Je to nutné? Ne. Ale je příjemné mít projektové tasky definované vedle verzí nástrojů na jednom místě.

Cesta migrace

Tohle mě přesvědčilo: Mise čte .sdkmanrc nativně. Mapuje SDKMAN vendor stringy na svůj formát — 21.0.2-tem se stane temurin-21.0.2. Vaše existující .sdkmanrc soubory prostě fungují.

Migrace je postupná:

1. Nainstalujte Mise: curl https://mise.run | sh
2. Přidejte do shellu: eval "$(mise activate zsh)"
3. Vaše existující .sdkmanrc soubory se načtou automaticky
4. Až budete připraveni, převeďte na .mise.toml pro plnou sadu funkcí

Nemusíte SDKMAN hned odinstalovat. Oba mohou koexistovat, zatímco přecházíte.

Co SDKMAN stále dělá lépe

Fér je fér:

• Šíře JVM ekosystému — SDKMAN podporuje více distribucí JDK (GraalVM, Liberica NIK, Bisheng), které Mise zatím nemá
• JVM-specifické nástroje — SDKMAN spravuje Gradle, Maven, Micronaut CLI, Quarkus CLI a další JVM nástroje nativně. S Mise některé vyžadují asdf pluginy
• Komunita — SDKMAN má roky důvěry JVM komunity a větší uživatelskou základnu v Java světě
• Kandidáti — sdk list java s tabulkou dostupných distribucí je skvělý discovery zážitek

Pokud je váš svět čistě JVM a nikdy se nedotknete Node/Pythonu/Terraformu, SDKMAN je stále vynikající. Argumenty pro Mise sílí s tím, jak se váš toolchain diverzifikuje.

Srovnání

Závěr

SDKMAN vyřešil reálný problém a vyřešil ho dobře. Používal jsem ho roky bez stížností. Ale Mise je to, jak by SDKMAN vypadal, kdybyste ho navrhli dnes — polyglotní, rychlý a vědomý si toho, že moderní projekty používají víc než jeden jazyk.

Pokud váš .zshrc načítá tři správce verzí, Mise je přímočarý upgrade. Pokud jste spokojení se SDKMAN a píšete jen Javu — nechte to. Není důvod přecházet jen proto, abyste přecházeli.

Ale pokud kolega zmíní Mise, zkuste to. Já to udělal a můj shell je o 200ms rychlejší a kořen projektu má jeden konfigurák místo čtyř.

Titulní foto: Patrick na Unsplash.