Dotenv: Boolean and null values

[mikeshawdev]

If there are environment variables set to null or false, they are cast as strings when saved to process.env

When they are read them into process.env there could be a check for boolean and null values, to ensure they are cast as such?

What do you reckon?

[maxbeatty]

If you're performing boolean logic based on environment variables, you could just check for "true"

if (process.env.SHOULD_SEND_EMAIL == 'true') {
  mailer.send()
}

You could also use a zero (0) or one (1) instead of null or false to achieve boolean logic. You can just omit from your .env when you want that "false" case.

SHOULD_SEND_EMAIL=1

if (process.env.SHOULD_SEND_EMAIL) {
  mailer.send()
}

[mikeshawdev]

Aye, you could do that. However, I would argue that this is unexpected behaviour. If I set a value in my .env file to true/false/null I would expect them to be cast as such in the environment

[bstanley0811]

I just ran into this same issue and I don't think you're suggestion for 1's and 0's will work. It seems that all env variables are coming over as strings, even numerical values, which makes your if condition always true.

Edit: After further research, it seems all environment variables are supposed to be strings. http://stackoverflow.com/a/10265271

[jcblw]

@bstanley0811 thanks for the info.

Here the documentation for process.env which is indeed all strings.

I would say process.env shouldn't be used for flags. If you do need one tho I would just not set the varible or set the variable to an empty string which is a falsey value.

[mikeshawdev]

Thanks @jcblw, looks to be that process.env forces everything to be strings no matter what. I didn't realise this before

I guess if you wanted to get booleans/null out of it you could move them into your own object and cast them as needed

Cheers!

[niftylettuce]

Hey guys I had this same issue so I built this plugin for dotenv at https://github.com/niftylettuce/dotenv-parse-variables. Hope it helps 👍

[centigrade-thomas-becker]

I did not expect .env to parse true and false as string values. I probably won't be the last person to make this assumption. Perhaps the Readme segment about parsing should be updated, or maybe a FAQ entry about booleans could clear things up.

[niftylettuce]

Use my package dotenv-parse-variables

On May 3, 2017 2:19 AM, "jacobsun" [e-mail] wrote:

I am handling cookies with secure flag, obviously I don't wanna secure to
true in development enviroment.
So I have tried true/false, 0/1, Boolean(process.env.SECURE_FLAG),
NONE OF THEM WORKS.
waste time, just type secure:false there.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/motdotla/dotenv/issues/51#issuecomment-298831219, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAf7hciX_-DOYKowTDikr8nNGO7cERnHks5r2BxygaJpZM4DhxsO
.

[emmanuelnk]

Sorry to beat a dead horse:
Even though it is true process.env reads booleans as strings, its unexpected that the package we download (dotenv) to help us manage envs better would do this as well. Packages should make coding easier and as this thread clearly shows, most developers would assume that dotenv loads booleans into nodejs as, well, booleans. Its not intuitive that we should download a whole plugin for what should be expected behavior. This is a great package (kudos to the devs despite this mini-critique) and I believe this should be a feature enhancement.

[dwaltrip]

It looks like the concept of "dotenv" originated with a Ruby library that was first released in 2012: https://github.com/bkeepers/dotenv. The google search trends for "dotenv" also support this: https://trends.google.com/trends/explore?date=all&geo=US&q=dotenv

This library, a nodejs implementation, was released in 2013. Due to javascript's growth, it does have more stars.

However, dotenv files are not javascript files. It seems like they are actually more closer to a Bash file than anything else?

I agree it would be useful to be able to have boolean values in a config file. However, it would also be nice if .env files were consistent. For example, in ruby the null value is spelled Nil, while of course in javascript it is null. Fortunately, true and false are spelled the same, but it could have easily been different. Python uses the spellings of True and False.

I don't have a clear answer here... I just wanted to draw some attention to this side of things, as I didn't see this aspect mentioned in any of the comments above.

[jessety]

Using env variables makes sense to maintain consistency between projects whether they're based on JavaScript or not. It follows that .env files themselves contain the same input as the shell variable.

That said, this does move type casting for numerical or boolean env values into your application logic. This can lead to duplication if you're using the same variable in multiple places.

After running into this issue, I wrote a new env loading library designed to handle type casting for both shell environmental variables and .env files: env-smart

I hope it's helpful to someone else who ends up here!

[centerorbit]

In my application, using Vue+Vuex, I'm using a store module to keep all of the app settings/config in one place (therefore removing myself from the process.env being all strings issue). I then parsed the dotenv like so:

var env = dotenv.parse('.env');
// Convert 'true' and 'false' to boolean, and numbers to numbers.
each(env, (value, key) => {
  if (value === 'true') env[key] = true;
  if (value === 'false') env[key] = false;
  if (value === 'null') env[key] = null;
  if (!isNaN(Number(value))) env[key] = Number(value);
});

Now my store is populated with the types that I'm expecting.