Deno: process.env.NODE_ENV pattern

[guybedford]

Has any thought been put to the replacement for the pattern process.env.NODE_ENV === 'production' etc in Deno?

I'm trying to work out what the right alignment here will be across tools going forward in ES modules.

I guess the direct analog would be Deno.env().NODE_ENV but that is immediately permission extending for all code that does that.

import.meta could make sense for this pattern, although ideally it should just be contextual module data there.

The next best thing seems to be a global.

Any ideas?

[zekth]

This may be achieved by Allow Once no?
See https://github.com/denoland/deno/pull/1926

Flags are currently refactored so it's not really well documented using Deno -h

[Janpot]

Personally I've always found NODE_ENV (or equivalents in other languages) to be a bit of an anti-pattern. It encourages to put configuration management inside of the app, while I believe it belongs outside of it.
e.g. instead of doing:

const endpoint = process.env.NODE_ENV === 'production' 
  ? `https://www.example.com/`
  : `https://test-env.example.com/`;

I always encourage our devs to prefer the pattern

const endpoint = process.env.ENDPOINT;

And use other tools to supply the correct values (we use docker-compose locally and kubernetes in test/production, but there's many other ways to persist environment variables and automatically supply, depending on how you run your code). It makes configuring special setups for local development, integration testing,... much much easier.

I understand this is a controversial standpoint and I recognize there's different valid opinions around this. But if it were up to me, deno would take an explicit stance against a NODE_ENV type of variable.

[zekth]

Totally agree with @Janpot .
So you can get your context of app using Deno.env() and store it in a variable. After that you only have one reading of the env.
@afinch7 what happened to allow once feature?

[guybedford]

Agreed this comes down to the lack of better primitives.

For example a major use case in Node.js as well here is the following:

if (process.env.NODE_ENV === 'production')
  require('./dep-production');
else
  require('./dep-dev');

Handling these kinds of conditionals at the resolver level sounds preferable to me. Ideally through import maps in Deno.