Mise (mise-en-place) hosting integration

[prom3theu5]

Related to an existing integration?

No

Existing integration

No response

Overview

Polyglot Aspire app hosts (node, go, python, dotnet, ...) currently assume every tool a resource needs is already installed on the developer's machine at the right version. Teams that standardise on mise (mise-en-place) already declare those tools in a mise.toml, but Aspire has no awareness of it: resources launch with whatever happens to be on the host PATH, npm install/go mod tidy setup steps run before the right toolchain exists, and "works on my machine" version drift creeps in.

This proposal adds a CommunityToolkit.Aspire.Hosting.Mise hosting integration so an app host can adopt a mise environment as a first-class resource:

• AddMise(name, configDirectory) runs mise install (trusted non-interactively via MISE_TRUSTED_CONFIG_PATHS/MISE_YES) before dependent resources start, visible in the dashboard with logs and exit code. mise itself is never installed by the integration (supply-chain concern) — if it is missing the app host fails fast with per-OS install guidance.
• WithMiseEnvironment(mise) injects the resolved mise env (tool paths and [env] variables) into any resource and waits for the install to complete. Because the orchestrator resolves bare executable commands against the app host's own PATH, such launches are wrapped with mise exec so they resolve to the mise-managed tool; explicit path commands are untouched. The binding automatically propagates to setup resources created by other integrations (the JavaScript {name}-installer child, Go's go mod tidy siblings) so those also run with mise-managed tools.
• Project resources run on the mise-managed .NET SDK via the mise shims directory (the orchestrator launches projects with a hardcoded dotnet the application model cannot rewrite).
• AddMiseTask("build") runs mise.toml tasks as resources; WithMiseExec(mise) wraps a launch explicitly.
• Everything is excluded from publish — mise is strictly a local development concern and leaves zero trace in manifests/deployment artifacts.

Usage example

var builder = DistributedApplication.CreateBuilder(args);

// Installs node 22, go 1.24, dotnet 10, ... from ../mise.toml before dependents start.
var mise = builder.AddMise("mise", "../");

mise.AddMiseTask("build");

builder.AddExecutable("web", "node", "../app", "server.js")
    .WithMiseEnvironment(mise);          // mise-managed node + [env] variables

builder.AddJavaScriptApp("frontend", "../jsapp")
    .WithMiseEnvironment(mise);          // npm installer child bound automatically

builder.AddGoApp("goapi", "../goapp")
    .WithModTidy()
    .WithMiseEnvironment(mise);          // go mod tidy sibling bound automatically

builder.AddProject<Projects.Api>("api")
    .WithMiseEnvironment(mise);          // runs on the mise-managed dotnet via shims

builder.Build().Run();

Breaking change?

No

Alternatives

• Documenting required tool versions and hoping developers keep their machines in sync (the status quo); WithRequiredCommand can warn a tool is missing but cannot install or version-pin it.
• Running everything in containers/devcontainers — heavier, and doesn't help the common "executables + projects on the host" inner loop that Aspire's executable resources exist for.
• Hand-rolling AddExecutable("mise", ...) + WaitForCompletion in every app host — possible, but misses environment injection, the bare-command PATH resolution pitfall, setup-resource propagation, and dotnet shims, which is exactly the boilerplate an integration should own.

Additional context

A complete implementation already exists and is ready to PR: https://github.com/prom3theu5/Aspire-CommunityToolkit/tree/feature/mise

It includes the integration (src/CommunityToolkit.Aspire.Hosting.Mise), 42 tests (34 unit + 8 integration tests that run the example app host end-to-end; integration tests skip on machines without mise), and an example app host exercising AddExecutable, AddJavaScriptApp, AddGoApp and AddProject from a single mise.toml (node 22, go 1.24, dotnet 10).

Help us help you

Yes, I'd like to be assigned to work on this item