get-dotenv

Load environment variables with a cascade of environment-aware dotenv files. You can:

✅ Asynchronously load environment variables from multiple dotenv files.

✅ Segregate variables info distinct files:

• Public files (e.g. .env, env.dev, env.test) are synced with your git repository.
• Private files (e.g. .env.local, env.dev.local, env.test.local) are protected by .gitignore.
• Global files (e.g. .env, env.local) apply to all environments.
• Env files (e.g. .env.dev, .env.dev.local, .env.test, .env.test.local) apply to a specific environment.
• Dynamic files (.env.js) export logic that dynamically & progressively generates new variables or overrides current ones.

✅ Dynamically specify which variables to load by type.

✅ Explicitly add variables to the loaded set.

✅ Extract the resulting variables to an object, process.env, a dotenv file, or a logger object, in any combination.

✅ Customize your dotenv file directories & naming patterns.

✅ Perform all of the above either programmatically or from the command line, where you can also execute additional commands within the resulting context... including nested getdotenv commands that inherit the parent command's settings & context!

✅ Execute batched CLI commands across multiple working directories, with each command inheriting the getdotenv context.

✅ Set defaults for all options in a getdotenv.config.json file in your project root directory.

✅ Generate an extensible getdotenv-based CLI for use in your own projects.

getdotenv relies on the excellent dotenv parser and somewhat improves on dotenv-expand for recursive variable expansion.

You can always use getdotenv directly on the command line, but its REAL power comes into play when you use it as the foundation of your own CLI. This lets you set defaults globally and configure pre- and post-hooks that mutate your getdotenv context and do useful things like grab an AWS session from your dev environment and add it to the command execution context.

When you plug your own commander CLI commands into the getdotenv base, they will execute within all of the environmental context created above!

Breaking Changes

In version 4.0.0, in addition to a full TypeScript refactor, I replaced the use of the unsafe Function constructor for dynamic variable processing with a MUCH safer dynamic module import.

Dynamic importing is intrinsically asynchronous, and so far I haven't been able to figure out how to cram that into the synchronous getDotenvSync function. There really aren't THAT many users of this library, so rather than have async & sync versions that do different things, I just eliminated the sync version entirely.

If you have a use case for sync dotenv processing and DON'T need dynamic variables, let me know and I'll put the restricted version back in. If you have an idea of how to make dynamic imports synchronous, I'm all ears!

Installation

1npm install @karmaniverous/get-dotenv

Usage

1import { getDotenv } from '@karmaniverous/get-dotenv';
2
3const dotenv = await getDotenv(options);

Options can be passed programmatically or set in a getdotenv.config.json file in your project root directory. The same file also sets default options for the getdotenv CLI or any child CLI you spawn from it.

See the child CLI example repo for an extensiive discussion of the various config options and how & where to set them.

Dynamic Processing

This package supports the full dotenv-expand syntax, with some internal performance improvements.

Use the dynamicPath option to add a relative path to a Javascript module with a default export like this:

1export default {
2  SOME_DYNAMIC_VARIABLE: (dotenv) => someLogic(dotenv),
3  ANOTHER_DYNAMIC_VARIABLE: (dotenv) =>
4    someOtherLogic(dotenv.SOME_DYNAMIC_VARIABLE),
5  ONE_MORE_TIME: ({ DESTRUCTRED_VARIABLE, ANOTHER_DYNAMIC_VARIABLE }) =>
6    DESTRUCTRED_VARIABLE + ANOTHER_DYNAMIC_VARIABLE,
7};

If the value corresponding to a key is a function, it will be executed with the current state of dotenv as its single argument and the result applied back to the dotenv object. Otherwise, the value will just be applied back to dotenv. (Although if you're going to do that then you might as well just create a public global variable in the first place.)

Since keys will be evaluated progressively, each successive key function will have access to any previous ones. These keys can also override existing variables.

Dynamic Processing with TypeScript

Even though the rest of your project is in TypeScript, the dynamic processing module SHOULD be in JavasScript.

Think about it: the module is loaded via a dynamic import, with the file name determined at run time. If you write this module in TS, you'll have to jump through some hoops to get your bundler to compile this file, and you'll have to be careful to set dynamicPath to reference the compiled file. That's a lot of work to do for some very simple logic.

BUT... if you must, then your dynamic module's default export should be of the GetDotenvDynamic type, which is defined here and looks like this:

1export type ProcessEnv = Record<string, string | undefined>;
2
3export type GetDotenvDynamicFunction = (
4  vars: ProcessEnv,
5  env: string | undefined,
6) => string | undefined;
7
8export type GetDotenvDynamic = Record<
9  string,
10  GetDotenvDynamicFunction | ReturnType<GetDotenvDynamicFunction>
11>;

The second argumnt env of the GetDotenvDynamicFunction type is the environment token (if any) specified in the controlling getDotenv call.

Command Line Interface

You can also use getdotenv from the command line:

1> npx getdotenv -h
2
3# Usage: getdotenv [options] [command]
4#
5# Base CLI.
6#
7# Options:
8#   -e, --env <string>                  target environment (dotenv-expanded)
9#   -v, --vars <string>                 extra variables expressed as delimited key-value pairs (dotenv-expanded): KEY1=VAL1 KEY2=VAL2
10#   -c, --command <string>              command executed according to the --shell option, conflicts with cmd subcommand (dotenv-expanded)
11#   -o, --output-path <string>          consolidated output file  (dotenv-expanded)
12#   -s, --shell [string]                command execution shell, no argument for default OS shell or provide shell string (default OS shell)
13#   -S, --shell-off                     command execution shell OFF
14#   -p, --load-process                  load variables to process.env ON (default)
15#   -P, --load-process-off              load variables to process.env OFF
16#   -a, --exclude-all                   exclude all dotenv variables from loading ON
17#   -A, --exclude-all-off               exclude all dotenv variables from loading OFF (default)
18#   -z, --exclude-dynamic               exclude dynamic dotenv variables from loading ON
19#   -Z, --exclude-dynamic-off           exclude dynamic dotenv variables from loading OFF (default)
20#   -n, --exclude-env                   exclude environment-specific dotenv variables from loading
21#   -N, --exclude-env-off               exclude environment-specific dotenv variables from loading OFF (default)
22#   -g, --exclude-global                exclude global dotenv variables from loading ON
23#   -G, --exclude-global-off            exclude global dotenv variables from loading OFF (default)
24#   -r, --exclude-private               exclude private dotenv variables from loading ON
25#   -R, --exclude-private-off           exclude private dotenv variables from loading OFF (default)
26#   -u, --exclude-public                exclude public dotenv variables from loading ON
27#   -U, --exclude-public-off            exclude public dotenv variables from loading OFF (default)
28#   -l, --log                           console log loaded variables ON
29#   -L, --log-off                       console log loaded variables OFF (default)
30#   -d, --debug                         debug mode ON
31#   -D, --debug-off                     debug mode OFF (default)
32#   --default-env <string>              default target environment
33#   --dotenv-token <string>             dotenv-expanded token indicating a dotenv file (default: ".env")
34#   --dynamic-path <string>             dynamic variables path
35#   --paths <string>                    dotenv-expanded delimited list of paths to dotenv directory (default: "./")
36#   --paths-delimiter <string>          paths delimiter string (default: " ")
37#   --paths-delimiter-pattern <string>  paths delimiter regex pattern
38#   --private-token <string>            dotenv-expanded token indicating private variables (default: "local")
39#   --vars-delimiter <string>           vars delimiter string (default: " ")
40#   --vars-delimiter-pattern <string>   vars delimiter regex pattern
41#   --vars-assignor <string>            vars assignment operator string (default: "=")
42#   --vars-assignor-pattern <string>    vars assignment operator regex pattern
43#   -h, --help                          display help for command
44#
45# Commands:
46#   batch [options]                     Batch shell commands across multiple working directories.
47#   cmd                                 Batch execute command according to the --shell option, conflicts with --command option (default command)
48#   help [command]                      display help for command

By default, commands (-c or --command or the cmd subcommand either in the base CLI or in the batch subcommand) execute in the default OS shell with the dotenv context applied. The -S or --shell-off options will turn this off, and Execa will execute your command as Javascript.

Alternatively, you can use the -s or --shell option to specify a different shell following the Execa spec. This is useful if you're running a command that requires a specific shell, like bash or zsh.

Finally, you can set the shell default globally in your getdotenv.config.json file.

See this example repo for a deep dive on using the getDotenv CLI and how to extend it for your own projects.

Batch Command

The getdotenv base CLI includes one very useful subcommand: batch.

This command lets you execute a shell command across multiple working directories. Executions occur within the loaded dotenv context. Might not be relevant to your specific use case, but when you need it, it's a game-changer!

My most common use case for this command is a microservice project where release day finds me updating dependencies & performing a release in well over a dozen very similar repositories. The sequence of steps in each case is exactly the same, but I need to respond individually as issues arise, so scripting the whole thing out would fail more often than it would work.

I use the batch command to perform each step across all repositories at once. Once you get used to it, it feels like a superpower!

Lest you doubt what that kind of leverage can do for you, consider this:

1> getdotenv batch -h
2
3# Usage: getdotenv batch [options] [command]
4#
5# Batch command execution across multiple working directories.
6#
7# Options:
8#   -p, --pkg-cwd             use nearest package directory as current working directory
9#   -r, --root-path <string>  path to batch root directory from current working directory (default: "./")
10#   -g, --globs <string>      space-delimited globs from root path (default: "*")
11#   -c, --command <string>    command executed according to the base --shell option, conflicts with cmd subcommand (dotenv-expanded)
12#   -l, --list                list working directories without executing command
13#   -e, --ignore-errors       ignore errors and continue with next path
14#   -h, --help                display help for command
15#
16# Commands:
17#   cmd                       execute command, conflicts with --command option (default subcommand)
18#   help [command]            display help for command

Note that batch executes its commands in sequence, rather than in parallel!

To understand why, imagine running npm install in a dozen repos from the same command line. The visual feedback would be impossible to follow, and if something broke you'd have a really hard time figuring out why.

Instead, everything runs in sequence, and you get a clear record of exactly what heppened and where. Also worth noting that many complex processes are resource hogs: you would not want to run a dozen Serverless deployments at once!

Meanwhile, this issue documents the parallel-processing option requirement. Feel free to submit a PR!

---

See more great templates & tools on my GitHub Profile!