Skip to content

Latest commit

 

History

History
134 lines (97 loc) · 3.38 KB

environments.md

File metadata and controls

134 lines (97 loc) · 3.38 KB

Environments

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'

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

Follow #1447 to see when this is available.

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. It would be possible to use different types of scripts, or binaries that are not scripts at all. See #1448 for information. :::

Multiple env._ Directives

Follow #1449 to see when this is available.

It may be necessary to use multiple env._ directives but TOML syntax won't allow 2 keys in a table like that:

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

To support that, you can optionally make [env] an array instead by using TOML's [[env]] syntax:

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

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

Follow #1262 to see when this is available.

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.