Environments

Like direnv it manages environment variables for different project directories.

Use mise to specify environment variables used for different projects. Create a mise.toml file in the root of your project directory:

[env]
NODE_ENV = 'production'

To clear an env var, set it to false:

[env]
NODE_ENV = false # unset a previously set NODE_ENV

You can also use the CLI to get/set env vars:

$ mise set NODE_ENV=development
$ mise set NODE_ENV
development
$ mise set
key       value        source
NODE_ENV  development  mise.toml
$ mise unset NODE_ENV

env._ directives

env._.* define special behavior for setting environment variables. (e.g.: reading env vars from a file). Since nested environment variables do not make sense, we make use of this fact by creating a key named "_" which is a TOML table for the configuration of these directives.

env._.file

In mise.toml: env._.file can be used to specify a dotenv file to load. It can be a string or array and uses relative or absolute paths:

[env]
_.file = '.env'

INFO

This uses dotenvy under the hood. If you have problems with the way env._.file works, you will likely need to post an issue there, not to mise since there is not much mise can do about the way that crate works.

Or set MISE_ENV_FILE=.env to automatically load dotenv files in any directory.

env._.path

PATH is treated specially, it needs to be defined as a string/array in mise.path:

[env]
_.path = [
    # adds an absolute path
    "~/.local/share/bin",
    # adds a path relative to the mise.toml, not PWD
    "./node_modules/.bin",
]

env._.source

Source an external bash script and pull exported environment variables out of it:

[env]
_.source = "./script.sh"

INFO

This must be a script that runs in bash as if it were executed like this:

source ./script.sh

The shebang will be ignored. See #1448 for a potential alternative that would work with binaries or other script languages.

Plugin-provided env._ Directives

Plugins can provide their own env._ directives. See mise-env-sample for an example of one.

Multiple env._ Directives

It may be necessary to use multiple env._ directives, however TOML fails with this syntax because it has 2 identical keys in a table:

[env]
_.source = "./script_1.sh"
_.source = "./script_2.sh" # invalid

For this use-case, you can optionally make [env] an array-of-tables instead by using [[env]] instead:

[[env]]
_.source = "./script_1.sh"
[[env]]
_.source = "./script_2.sh"

It works identically but you can have multiple tables.

Templates

Environment variable values can be templates, see Templates for details.

[env]
LD_LIBRARY_PATH = "/some/path:{{env.LD_LIBRARY_PATH}}"

Using env vars in other env vars

You can use the value of an environment variable in later env vars:

[env]
MY_PROJ_LIB = "{{config_root}}/lib"
LD_LIBRARY_PATH = "/some/path:{{env.MY_PROJ_LIB}}"

Of course the ordering matters when doing this.