This should be like @xorander00 explained in #941, right?

have a setting to specify the file(s) to load and the order in which to load them ... look for and load from left-to-right (later loaded dotenv files overriding values from previously loaded ones).

And if one isn't found, silently (?) skip it?

Yeah, that's right. If a user wants it to be an error if an environment file isn't found, we could add another setting, like set dotenv-require := true, which would default to false, and make just return an error if an environment file isn't found

Just saw this, sweet! :) Will build from latest commit & give it a shot this weekend and report back if I run into any issues.

@casey I think that would be a good setting, yes. Although personally, I'd consider making it a numeric (or enum-like) state flag instead of a boolean toggle. Not sure how it would work in just, but something like dotenv-missing := 0 | 1 | 2. 0 being silently ignore and continue, 1 being warn and continue (default), and 2 being fail and exit. This offers more flexibility for the user as well as for the future (additional cases can just be new numbers). Just my personal preference though and not a huge deal.

@casey I think that would be a good setting, yes. Although personally, I'd consider making it a numeric (or enum-like) state flag instead of a boolean toggle. Not sure how it would work in just, but something like dotenv-missing := 0 | 1 | 2. 0 being silently ignore and continue, 1 being warn and continue (default), and 2 being fail and exit. This offers more flexibility for the user as well as for the future (additional cases can just be new numbers). Just my personal preference though and not a huge deal.

I think that would be reasonable. And it can always be a keyword, like dotenv-missing := continue | warn | error, so it's easier to remember.

@casey Can we change .env file in recipe? Like this:

# Start application in dev mode with .dev-env supported
start-dev:
  set dotenv-filenames := [".env", ".dev-env"]

# Start application in test mode with .test-env loaded
start-test:
  set dotenv-filenames := [".env", ".test-env"]

@casey Can we change .env file in recipe? Like this:

I think it's probably impossible to change a .env file once a recipe runs. Different parts of a justfile could read from different environment files, depending on when they ran, which would be super confusing.

@casey Can we change .env file in recipe? Like this:

Different parts of a justfile could read from different environment files, depending on when they ran, which would be super confusing.

Thanks for your reply. As the example I gave above: it's quite common that when a APP starts in dev mode with envs different from in test mode, such as DB config, backend service URL, etc. How to achieve this ?

Thanks for your reply. As the example I gave above: it's quite common that when a APP starts in dev mode with envs different from in test mode, such as DB config, backend service URL, etc. How to achieve this ?

I'm not entirely sure. There's a complication here, which is that just doesn't support arrays, so there's no way to do:

set dotenv-filenames = if FOO == BAR { [".env-dev"] } else { [".env-prod"] }

Since an expression can't be of type array, only string.

You could use just --dotenv-filename NAME to select which one you want when invoking just, perhaps making the dev version .env, and passing just --dotenv-filename .env-prod when you want to run in production mode.

Got it, Thanks

I'd like to suggest one more thing with regards to loading of the .env - it would be usefull if instead of just a file, you could provide a command to run (that would output the .env content to STDOUT). This would (for instance) enable me to load secrets from 1password cli by doing something like set dotenv-load = op inject -i .env:

I like @Alxandr proposal,

I just created an issue with a general solution as the goal : #1584

The extra requirement on my side is to be able to parametrize the loading too

At the moment, it seems that it's not possible to load a specific path for the .env file from within the justfile, even though it is from the command line. Does that sound right? I did do a lot of searching

What if it could all happen using the same dotenv-load variable? Currently that's a boolean only, but can it be extended to test for a string? And if it's a string then it's the path to the .env file itself?

Regarding being able to use arrays for multiple... This seems to work: set shell := ["bash", "-uc"] .. isn't that an array? But even being able to load one would be nice... perhaps to load multiple, just use source other-env-file.env from within the .env file itself? That would take some weight off of just for loading multiple if it's possible

Is it correct that currently the way to load an .env file is automatically from either the current or parent directory, and there is not an option to specify a path?

Here is a use case why setting a custom path would be helpful: NextJS projects have a convention of putting the .env file into source control and only setting default values there. So you would need to be able to load .env.local to use just in such a project.

Implemented in #1692.

Hey @casey, I was wondering if there are plans to support multiple dotenv files? It seems like the PR implemented only support a single dotenv file compared to what was proposed here.

It would be great to be able to have Just load dotenv files like in https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use.

Thanks! 🙌

@evandam I'm not opposed! I think it was just left out to make the initial implementation simpler. Can you create a new issue and describe your use case? In particular, I'm curious if you want to load multiple dotenv files at the same time, or if to go through a list of dotenv files, and load the first one that's found.

Hey @casey just mentioning it here for reference, I opened #1748 - hopefully it all makes sense!

Thanks again 🙌