Add EnvExists cheatcode

[vicnaum]

Component

Forge

Describe the feature you would like

Proposing to add a cheatcode like envExists(string calldata key) returns (bool) that will return true if the ENV key exists, and false if it doesn't exist.

Reasoning:
Right now there is no way to check if a specific ENV variable was set, and the whole script just reverts. This doesn't allow to have optional ENV keys, and requires setting all ENVs explicitly, even if they're optional for some test cases.

Examples:

• Having a FORK key to test on a fork VS testing on a local deployment. Currently the FORK= ENV variable should be present for the tests to run at all, even if the FORK is not used. Things get complicated if there are many such optional variables.
• Having a MNEMONIC or PRIVATE_KEY variables - there is no sense to have both of them - can use either. But with current behavior they both should be set (one left as an empty string) for the script to not revert.

Additional context

No response

[mattsse]

I can see how having a envIsSet() code is useful.

a workaround for this is something like:

  try vm.envBool("MYVAR") returns (bool myVar) {
            if (myVar) {...};
        } catch {
           
        }

[mds1]

Partly related to foundry-rs/forge-std#226, where we discuss how vm.parseJson returns an empty string if the provided key isn't found, and we'll add a keyExists helper method to validate the result. One issue with doing the same here is then you can't support env vars that are actually empty.

I've used the try/catch workaround in the past, and try/catch was introduced in solidity 0.6.2, so we can implement that workaround in forge-std too. Perhaps something like tryEnvBool(string name, bool default) where the second arg is the default return value if not found

[mds1]

@mattsse if you think the forge-std solution is the preferable way to handle it / @vicnaum if you're ok with that solution lmk, and in that case can we transfer this issue to forge-std?

I'm unsure whether the forge-std solution or an envIsSet cheatcode is preferable, curious to hear thoughts here

[vicnaum]

@mattsse Oh, for some reason I remember try/catch not working for me before, but maybe I'm just confusing it with smth else (I definitely saw Try can only be used with external function calls and contract creation calls. when I was trying to parse non-existing JSON keys).

But in this case of ENVs - it works! So yes, as @mds1 says - we can go with forge-std solution with try/catch - that sounds perfectly fine (I just was mistakenly thinking that try/catch wouldn't work, but it does).

I just have several questions I want to discuss before I start:

• If we want universal isEnvSet helper - am I correct that vm.envString is the most universal solution that wouldn't fail on any key value, and only fails when the key doesn't exist?
• Should it be envIsSet or isEnvSet? I'm leaning towards isEnvSet but would like to hear your opinions.
• Are you ok with me creating StdEnv.sol and putting all the helper functions (like tryEnvBool() etc) there?
• What's the best way to create an environment fixture for testing? Should I do setEnv in setUp, or better init from a file? If file - then how? My forge test doesn't automatically load .env for some reason, only if I source it beforehand (and use export keyword).

[mattsse]

isEnvSet

sgtm, let's add that

[alcueca]

May I suggest a different implementation?

Instead of isEnvSet (or maybe as an addition to it), the current env* functions should be overloaded to accept an extra parameter, and if the environment variable is not found, the extra parameter is returned.

Example:
bool mock = vm.envBool("MOCK", true) would assign the contents of $MOCK to mock, or true if $MOCK is not set.
string memory network = vm.envString("NETWORK", "mainnet") would assign the contents of $NETWORK to network, or "mainnet" if $NETWORK is not set.

The existing vm.env* methods should of course stay, in case users prefer the call to revert if the variable is not set.

Just a suggestion that would fit better my use case, feel free to ignore it. I'll be happy if this is implemented in any way.

[mattsse]

this is pretty useful and could be added easily, don't think we'd run into issues with solidity here.

But I think isEnvSet is still useful on its own to check if a var is set, regardless of the type of value it holds.

[vicnaum]

May I suggest a different implementation?

Instead of isEnvSet (or maybe as an addition to it), the current env* functions should be overloaded to accept an extra parameter, and if the environment variable is not found, the extra parameter is returned.

Example: bool mock = vm.envBool("MOCK", true) would assign the contents of $MOCK to mock, or true if $MOCK is not set. string memory network = vm.envString("NETWORK", "mainnet") would assign the contents of $NETWORK to network, or "mainnet" if $NETWORK is not set.

The existing vm.env* methods should of course stay, in case users prefer the call to revert if the variable is not set.

Just a suggestion that would fit better my use case, feel free to ignore it. I'll be happy if this is implemented in any way.

This sounds amazing! I like that.
Ok, will implement both.

[mds1]

+1 to @alcueca's suggestion, came to this issue to make the same comment in favor of the solution in foundry-rs/forge-std#237

Thanks for implementing @vicnaum!

[vicnaum]

+1 to @alcueca's suggestion, came to this issue to make the same comment in favor of the solution in foundry-rs/forge-std#237

Thanks for implementing @vicnaum!

Oh wait, I've meant implementing that in Solidity, cause I don't know any Rust (yet). Now I see those are all native vm.cheatcodes (not solidity helpers like the JSON case) - so I won't be able to overload them in Rust, sorry :-/

Anyways, when I looked at what's available, I have concerns about these array with delimiter functions, and especially envString one:

foundry/testdata/cheats/Cheats.sol

Line 39 in 54ec8e3

function envString(string calldata, string calldata) external returns (string[] memory);

It's (string,string) - so it will clash with overloaded (string key, string default) one, I guess?

[mds1]

It's (string,string) - so it will clash with overloaded (string key, string default) one, I guess?

Good point, what if we call all the new functions here vm.envWithDefault(string name, <defaultVal>) instead?

• Avoids the clash pointed out above
• Since the default vals are all different types, the methods can have the same name with the overloads to distinguish them

[slvDev]

Good point, what if we call all the new functions here vm.envWithDefault(string name, <defaultVal>) instead?

@mds1 please take a look at my implementation - created a pull request here #3810

[vicnaum]

Should we also modify Vm.sol in forge-std repo to make it work?

[gakonst]

Yep!

[mds1]

We have vm.envOr, and I'm not sure of a use case for vm.isEnvSet where you strictly care about if it's set and don't care about it's value, so going to close this. However if someone does have a need for isEnvSet feel free to create a new issue