You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suggest making --env-file work like --env for the following two reasons:
It's more obvious that it'll take a path to an .env file and not i.e. a ENV_VARIABLE=VALUE pair, or like jest --env takes an environment such as jsdom. This would clear up confusion with the Deno API's that actually does take variables such as --allow-env and --deny-env:
--allow-env[=<VARIABLE_NAME>...]
Allow access to system environment information. Optionally specify accessible environment variables.
Docs: https://deno.land/manual@v1.45.5/basics/permissions
Examples:
--allow-env
--allow-env="PORT,HOME,PATH"
--deny-env[=<VARIABLE_NAME>...]
Deny access to system environment information. Optionally specify accessible environment variables.
Docs: https://deno.land/manual@v1.45.5/basics/permissions
Examples:
--deny-env
--deny-env="PORT,HOME,PATH"
It's called --env-file in both node and bun, and having it be the same in Deno reduces cognitive overhead, and mitigate migration issues.
The text was updated successfully, but these errors were encountered:
I suggest making
--env-file
work like--env
for the following two reasons:--env-file
in both node and bun, and having it be the same in Deno reduces cognitive overhead, and mitigate migration issues.The text was updated successfully, but these errors were encountered: