Request: NPM/Node Compatibility: Better handling for process.env

[NfNitLoop]

I'm loving Deno's NPM compatibility, but there's a pain point: Lots of npm dependencies try to read various environment variables when they're loaded, which runs into Deno's permission prompt.

For example, @bufbuild/protobuf tries to read "BUF_BIGINT_DISABLE" to change its handling of bigints.

Loading npm:chalk tries to access all of these variables:

./chalk.ts
┏ ⚠️  Deno requests env access to "FORCE_COLOR".
┠─ To see a stack trace for this prompt, set the DENO_TRACE_PERMISSIONS environm
❌ Denied env access to "FORCE_COLOR".
┏ ⚠️  Deno requests env access to "TF_BUILD".
┠─ To see a stack trace for this prompt, set the DENO_TRACE_PERMISSIONS environm
❌ Denied env access to "TF_BUILD".
┏ ⚠️  Deno requests env access to "TERM".
┠─ To see a stack trace for this prompt, set the DENO_TRACE_PERMISSIONS environm
❌ Denied env access to "TERM".
┏ ⚠️  Deno requests env access to "CI".
┠─ To see a stack trace for this prompt, set the DENO_TRACE_PERMISSIONS environm
❌ Denied env access to "CI".
┏ ⚠️  Deno requests env access to "TEAMCITY_VERSION".
┠─ To see a stack trace for this prompt, set the DENO_TRACE_PERMISSIONS environm
❌ Denied env access to "TEAMCITY_VERSION".
┏ ⚠️  Deno requests env access to "COLORTERM".
┠─ To see a stack trace for this prompt, set the DENO_TRACE_PERMISSIONS environm
❌ Denied env access to "COLORTERM".
┏ ⚠️  Deno requests env access to "TERM_PROGRAM".
┠─ To see a stack trace for this prompt, set the DENO_TRACE_PERMISSIONS environm
❌ Denied env access to "TERM_PROGRAM".
Success!

(There's a request at #25208 to add a "deny all" option to the interactive prompt for just this case.)

You can currently work around this by adding a --deny-env to your script invocation, but it's not great UX to force every user of your script to deny it some permissions:

deno run -NR --deny-env jsr:@my/script

"Why do I have to deny permissions? Is it not secure?"

This gets even more complicated if your own script needs to read some environment variables. To run with the most restrictive set of permissions, and no unnecessary user prompts, you end up with something like:

deno run -NR --deny-env=FORCE_COLOR,TF_BUILD,TERM,CI,TEAMCITY_VERSION,COLORTERM,TERM_PROGRAM --allow-env=MY_ENV_VAR

I expect many will just end up granting blanket environment variable access with -E to not have to deal with this, which seems less than ideal.

Brainstorming

The first thing I reached for was Deno.permissions.denySync. But it doesn't exist.

With it, I was hoping that I could do something like this in my main.ts to deny permissions before loading dependencies.:

Deno.permissions.denySync({
    name: "env",
    variable: "…"
})

But maybe there is good reason not to allow denying permissions from the API? I could see it being a headache if some dependency denied global permissions so now you're not allowed to request them.

---

Maybe there's room for a more node-centric fix? Some API that says to make process.env just return undefined for some known variables?

Or a way to inject my own handler for process.env? That could allow me to inject appropriate values for those environment variables without having to resort to system access.

[BlackAsLight]

The easiest way to deal with this is to use the tasks in deno.json. Set up your long command in there with all the flags you want and then just call deno task run. It's great for wanting a lot of configurability without having to type or remember to type everything out.

[NfNitLoop]

@BlackAsLight Yep! I do this during development. But I'm writing software for others to use, via JSR, so they'll have to re-specify the same permissions on their CLI when they run or deno install --global the script.

If I didn't care about security I could tell them to just "deno run -A", but… 😬