dotenv: different behaviour between `load.ts` and `mod.ts` when used together with `run --watch=`
Describe the bug
When using Deno's watcher (deno run --watch=file,folder/ …) in conjunction with dotenv, I get different behaviour with auto loading compared to using config(). I'm not sure whether the fault lies with dotenv or Deno.env's handling of changes, though.
On a watcher-triggered reload, when using auto-loading, eventual changes in .env will not be available via Deno.env. When using config(), they are available.
Background: I was implementing an .env-based Deno Fresh server configuration (setting the HTTP port etc.) when I noticed that the file changes weren't picked up.
Steps to Reproduce
- Create initial
.envfile:
MY_ENV_VAR=foo
- Create
app-config.ts:
import { config } from "https://deno.land/[email protected]/dotenv/mod.ts";
console.log((await config())["MY_ENV_VAR"]);
- Run
app-config.tsand note the current output, "foo":
deno run -A --watch=.env app-config.ts
- Create
app-load.ts:
import "https://deno.land/[email protected]/dotenv/load.ts";
console.log(Deno.env.get("MY_ENV_VAR"));
- Run
app-load.tsand note the current output, "foo":
deno run -A --watch=.env app-load.ts
- Change contents of
.envfile:
MY_ENV_VAR=bar
- The watcher will reload
app-config.ts, the output will be "bar". - The watcher will reload
app-load.ts, the output will still be "foo".
Expected behavior
I expect both scripts to behave the same, they should both output "foo".
Environment
- OS: macOS 12.5 (21G72)
- deno version: 1.24.0
- std version: 0.150.0
Importing/executing dotenv/load.ts will export the parsed values to the environment of the current process, i.e. it will do Deno.env.set for each variable, unless the variable is already set in the environment.
dotenv.config() will not export anything to the environment, but if you do dotenv.config({ export: true }), it will behave identically.
On a side-note, --watch will not restart the entire process, just the main worker, so any changes that you make to the process environment will persist in your subsequent reloads. Maybe someone should clarify that in the CLI help text for --watch...
Anyway, I think this can be closed