feat(compile): support --env

[HasanAlrimawi]

Supported the use of --env flag with the compile subcommand, so that the generated executable/binary file can access the passed env file.

The commit is made to address issue #22105 .

Use-case
deno compile --env=some_env_file file_using_env_vars.js -> executable/binary file "file_using_env_vars" is created.
file_using_env_vars to run it.

The problem that prevented the generated executable from finding the env file's environment variables

• Through the compile subcommand flow, CliOptions are made by CliOptions::new and so is the env file passed.
• Within the same function, environment variables found in the env file were loaded using the dotenvy crate which uses the std::env::set_var.
• The std::env::set_var sets the env variables exclusively for the currently running process, and thus the env variables loaded within compile time are exclusive for the operation itself "The compile operation".
• When you try to run the generated executable file, then a new process will take the responsibility, and this process doesn't have the environment variables loaded.

Solution of the problem
Pass the environment file to the executable/binary file, then load the environment variables whenever the file is ran.

Code changes

A) Added an attribute to hold the environment file name to Metadata struct within deno/cli/standalone/binary.rs, since the metadata is passed to the binary file by fn write_standalone_binary().

B) Added a getter for the environment file name to the CliOptions methods, since the Flags attribute that holds env_file attribute is private.

C) Added fn load_env_variables_from_env_file() to deno/cli/mainrt.rs which will be responsible for loading the env variables from the environment file at execution time.

@dsherret
@littledivy

[HasanAlrimawi]

Hello @dsherret,
Just a kind reminder of this pull request.
Could you please review the latest changes? As this will help us proceed with applying more changes if needed or merging the changes if everything looks good.

[dsherret]

Sorry, just looking at this PR in detail. I'm not so sure about just providing a reference to the file because the file won't necessarily exist at runtime. Probably we need to embed the env variables into the executable and warn that we're doing it.

[HasanAlrimawi]

Makes sense.
I'll sort it out according to your vision.

[HasanAlrimawi]

Hello @dsherret ,

I made changes to embed the env variables from the env file into the generated executable and to warn the user about this action.
When running the executable, it will load the embedded variables as env variables.

[birkskyum]

Maybe it's worth using --env-file like node (and bun). It's more self-explanatory.

[dsherret]

@birkskyum the flag already shipped in Deno a while ago as --env. It just hasn't been part of deno compile.

[dsherret]

LGTM. Thanks @HasanAlrimawi!

[bartlomieju]

@birkskyum I would suggest opening a separate issue if you think the flag name should be changed. It's still possible for Deno 2.

[birkskyum]

@bartlomieju sure, I made a ticket here:

• Make deno --env-file work like --env #24528