BREAKING(dotenv): Fix dot env permissions

[cknight]

Addresses #3572

Headline changes

• BREAKING: remove restrictEnvAccessTo configuration option
• Additional documentation added, including commentary on permissions
• Removed all module dependencies
• Fixed bug (see below)
• Refactored tests, added additional tests

Overview

This is a breaking change, primarily to remove the restrictEnvAccessTo configuration option. To allow expansion of .env variables to use values from the process environment, the original implementation read the entire process environment into memory. This mean all users of dotenv required the --allow-env permission. Accessing all process variables was undesirable if you only needed to expand a single env variable, so restrictEnvAccessTo was added to restrict which env variables dotenv had access to and allow the granular --allow-env=SOME_VAR to work properly. This setup deviates away from how Deno handles permissions.

This change now allows for per-env-var access with no code configuration required and if you don't export any variables or expand any process variables then no --allow-env permissions are needed at all. The below examples show before and after permission handling:

Permission example 1

#.env
HELLO=world

// mod.ts
import { load } from "https://deno.land/std@0.199.0/dotenv/mod.ts";
await load();

Before change: Run with deno run --allow-read --allow-env mod.ts

After change: Run with deno run --allow-read mod.ts

Permission example 2

#.env
HELLO=${A}

// app.ts
import { load } from "https://deno.land/std@0.199.0/dotenv/mod.ts";
await load();

Before change: Run with A=world deno run --allow-read --allow-env mod.ts (full env access still required)

After change: Run with A=world deno run --allow-read --allow-env=A mod.ts (granular access allowed)

Permission example 3

#.env
HELLO=${A}

Before:

import { load } from "https://deno.land/std@0.199.0/dotenv/mod.ts";
await load({restrictEnvAccessTo: ["A"]});

Run with A=world deno run --allow-read --allow-env=A mod.ts (granular access only works with code grant to A via restrictEnvAccessTo)

After change:

import { load } from "./mod.ts";
await load();

Run with A=world deno run --allow-read --allow-env=A mod.ts (no code change required for granular access)

Bug fix

When expanding a process environment var who value was blank, the existing code was setting the configuration value to undefined rather than empty string.

#.env
HELLO=${A}

Before:

// mod.ts
import { load } from "https://deno.land/std@0.199.0/dotenv/mod.ts";
console.log(await load());

Run with A= deno run --allow-read --allow-env mod.ts yields:

{ HELLO: "undefined" }

After change:

// mod.ts
import { load } from "./mod.ts";
console.log(await load());

Run with A= deno run --allow-read --allow-env=A mod.ts yields:

{ HELLO: "" }

Additional consideration

As this is a breaking change, it may be desirable to consider #3561 as well, which would also be a breaking change to dotenv. However, as there is no feedback on that proposal to date no PR for that change has been progressed.

[cknight]

Any ideas why the linter is failing? Also failing locally for me, but I'm not sure how to fix it.

[iuioiua]

std/streams/readable_stream_from_iterable.ts needs to be deleted as it's deprecated. Best doing that in another PR.

[kt3k]

Let's keep this option only in typing in a few versions to prevent immediately breaking users code (in type checks)

[kt3k]

Thanks for adding these lines.

[kt3k]

LGTM. Nice clean up and fix!