2024.2

[jdx]

Here's an update of what's new since 2024.1. I'm planning to do a monthly announcement like this and this is the first one. This was a huge month—don't expect the same amount of content in March. The name change and task release made for a ton of work to be done but that's thankfully starting to slow down. Expect a slower pace from here on out like we had most of 2023.

For context to those new to the project: mise went through a name change from rtx as well as a big roadmap change. It used to be a simple asdf replacement but the scope was broadened—generally speaking this just means it has support for tasks. Because of that new project direction, there was a ton of stuff I wanted to get out asap. Most of it is here now and it's time to let things bake, patch bugs, tweak UX, etc. It's good for everyone that the pace isn't going to be like the previous 60 days.

Anyhow, this is not a comprehensive list of changes but just the things that I think would be most helpful to call out.

backends

backends are so good. I'll just show a quick sample to demo:

$ mise use -g npm:prettier@latest
$ mise use -g cargo:eza@latest

You don't need an asdf plugin to install CLIs anymore! These are also "global" so when you change node/rust versions you keep all the CLIs that were previously installed.

mise up --interactive

A little TUI for updating out of date tools!

Check out demand if you want to make CLIs like this in rust

python installs très vite!

By default we no longer use python-build and compile python—we use precompiled binaries. This makes python installs like 20x as fast as before! They don't work for all use-cases though, see the python docs for details on disabling this if you have trouble.

settings

"settings" have been overhauled in many, many ways. If you want to personalize mise, the settings are the right place to do it. Expect to see a lot more improvements when it comes to settings and new functionality

$ mise settings set status.missing_tools always # customize the "missing tools" warning
$ mise settings set all_compile true # do not use precompiled runtimes—useful for alpine/nixos users

env._

Without a shadow of a doubt the most controversial addition to mise has been env._. Despite that, it will enable some pretty powerful stuff and has already resolved some very longstanding feature requests.

This is a namespace of what I call "env directives" that modify the environment variables with some logic. The "_" just signifies that it is not a normal env var, instead it's going to run some subroutine of some kind.

For example:

[env]
NODE_ENV = "production"
_.file = ".env" # injects the contents of this dotenv file
_.path = "./node_modules/.bin" # adds this directory to PATH

This existed before, but the syntax has changed*. The reason for this new syntax is that it allows you to use env vars previously defined:

(*old env_file syntax still works and probably will for a long time but it's no longer documented)

[env]
MY_WORKSPACE="{{env.HOME}}/mydir"
MY_WORKSPACE_CACHE="{{env.MY_WORKSPACE}}/cache"

These work with directives too.

env._.source is a brand new directive that lets you execute some bash code:

[env]
_.source = "some_script.sh"

where some_script.sh could be anything that exports env vars:

export FOO=bar

This could be useful if you want a little script to set something like VIRTUAL_ENV—for example. It's a much simpler way to

More things will be moved here soon like virtualenv in python. It will also be possible for plugins to create their own directives.

Another necessary feature around this will be caching. Adding a env._.source script will need to run every time mise runs and it will slow down your terminal because bash is slow s until caching lands, be judicious about what you put in here (or perform caching on the bash side).

Also to come is wiring this up to tools—a long-standing feature request. This will allow you to set env vars for tool installation or activation—like if you want to enable a debug flag or something.

Anyhow, I have not done a great job at "selling" this concept. I am 100% convinced it's right for this project and I suspect it will make things "just work" in a way that you expect without needing to know the details. Consider it an "under-the-hood" improvement that's resulted in some quirky syntax but will generally just make things good later. I think that's best for all of us. A lot of people seem to dislike this. If that's you, well too bad, this is what we're going with. Don't forget this is a MIT licensed codebase—you're welcome to fork it and use env_file for the rest of your life if that's what you'd prefer!

"missing tool" warnings

Warnings are very tricky to get right in a tool like mise that typically runs every single time you run any command. I want to provide helpful warnings to let you know about potential problems without being annoying.

There is one warning in particular that is both extremely useful and extremely annoying: missing versions.

If you enter a directory with a .mise.toml with a node version you don't have installed, it might be nice to see a warning about that. However, you might not care that the version is missing—therefore you'll see a warning every time you run a command.

I want to provide a bit of customization because users clearly feel differently about this. However I want some really good defaults.

Anyhow, the logic as of this writing defaults to "only warn if the tool has at least 1 other version installed". So if you use mise for node on some other project, it'll warn if the version is missing. If you don't want to manage node with mise, it won't warn.

See the "status" setting for details on how to configure this behavior. And let me know how you feel about this behavior. This logic has had a lot of opinions on many sides and I know we're not there yet. Thankfully this is the sort of thing that isn't a breaking change, so it's pretty easy to modify if it's not working.

"not found" handler

Related to the last point, in mise if a version is not installed but you try to run it, mise by default will launch a "not found" handler that will attempt to install it automatically. Like the warning, this only happens if you have at least 1 version of the tool installed.

In other words, if you try to run npm in a project but are missing the expected version and don't have npm installed outside of mise, it will automatically install it before running npm. I think this will give a pretty good developer experience where mise does what you want without getting in the way—because in this scenario all it is overriding is the shell erroring out with a "command not found" error.

You can disable this if you don't want it with mise settings set not_found_auto_install 0. It works for both mise activate and shims.

Tasks

...you know I'll just save it for next time. Tasks are fantastic—I'm using them in several projects and loving it. In fact I use tasks more than I've used anything in mise so far. They're also experimental and while they function well understand they will be going through design changes. My advice: play around with them, let me know what you think, don't be afraid to use them in a project SO LONG as you don't mind patching some API changes along the way.

Thanks

This project has been incredibly fun for me to work on. I love that my little tool has been so helpful for so many people. I'm extremely appreciative of all the discussions people have with me and the contributions. This project has recently shifted from being a one-man show to being the product of a lot of people coming together and I couldn't be happier about that. I've also been receiving many emails from happy users that has really warmed my heart. I'm so glad y'all seem to love this thing.

There's a few people I want to call out specifically:

• @pepicrft - mise's biggest promotor by far and a great person to brainstorm ideas around, also member of the advisory board
  
• @booniepepper and @chadac - members of the mise advisory board and a huge, constant help figuring out some tricky design problems I've had
• @Ajpantuso - an incredible rust dev that's shipped a ton of new features lately. Tasks is really coming along thanks to @Ajpantuso.
• @roele - another great rust dev that picked up a ton of work I had on our demand library that mise uses. Check it out if you want a rust CLI prompt library! I think it's the best in the ecosystem.

[jdx]

I realize I didn't end up following through about making this a monthly thing, one reason for this is that I created a changelog and started following conventional-commit to have a better changelog.

That said, I know I leave a lot to be desired when it comes to this information. I do like the idea of having a monthly thing like this, but maybe I can do it every 6 months? idk

Just posting to say I haven't forgotten about this idea, just need to find something that fits my life.