Using '.env.js' extension and exporting an object sets all env variables as string

[marnixhoh]

Hi,
I use a config file with an '.env.js' extension and it exports an object with env variables. I noticed that these are set as strings, even though some of them are actually integers. Now I am not sure if this is expected behavior or not, but if there is some sort of workaround besides parsing the variables to integers every time they are used, that be great!

Thanks!

[toddbluhm]

Interesting, I was not aware of this behavior. This is something I will look into.

If you provide a number type as the value to an env var, it should remain a number and not get auto-converted to a string.

[marnixhoh]

Yes that is what I thought too. It also automatically converts booleans to strings...
Let me know if there is anything I can do to help

[alegmal]

@marnixhoh can you please take a look at this issue I opened here and see what I'm doing wrong?
I cant seem to use *.js for env files

#208

[JayV30]

This issue also effects .env-cmdrc files. I don't know if the intention is to covert all values in the file to strings, but it does.

Booleans are converted to strings.

Number types are converted to strings, no using 0, 1 in place of booleans. (although this is what I'm doing and parseInt() the variable in the application)

This makes working with env-cmd somewhat more difficult. I feel like this was not always the case as I've used this in the past without issue. Perhaps a recent version introduced different parsing of the values? I'm experiencing this issue with v10.1.0

[phatNfqAsia]

I am getting this misbehaviour too, @toddbluhm please confirm with me that you are still open for PR then I will find a way to fix this 🙏

[k-yle]

This is intentional, environment variables are always strings, on all operating systems. There's some more background info on wikipedia.

[toddbluhm]

So this is an interesting question. I am not really sure where to stand on this myself. Clearly, earlier I was leaning towards interpreting the string values, and currently in master after my brief re-write to update for the lastest node versions and esm it does now interpret the values so 1 === typeof Number, true === typeof Boolean.

I am curious if this will break a ton of stuff, or if it doesn't really matter. I know it will matter for those using the API, but I wonder if process.env will always return string values regardless. Something to look into or add to test cases...

It might be better to revert the functionality to keep them always strings just for consistency with all previous versions. I am open to persuasion either way.

[k-yle]

Since environment variables are always strings when loaded through process.env, it might be more consistent to only use strings in the API. Typescript errors if you try to load anything other than a string; the warning is currently silenced here:

env-cmd/src/env-cmd.ts

Line 52 in 7166412

env: env as Record<string, string>,

---

I can only think of 1 minor risk of using booleans/numbers:

• people often use 1 as a shorthand¹ when setting boolean environment variables
  (such as X=1 npm start)
• However, people sometimes write typeof process.env.* == "string" to check if an environment variable exists². This check would fail if the value is loaded as a boolean or number.

---

With that said, it seems like there are only 2 public repositories using env-cmd's API³. So the impact would be fairly minor

Footnotes

1. GitHub search query: =1 npm ↩

2. GitHub search query: typeof process.env.+==["']string ↩

3. GitHub search query: from ["']env-cmd ↩

[toddbluhm]

@k-yle you have persuaded me, I am good with keeping it strings and also not breaking backward compatibility. I can try to throw together a fix for that sometime, or you can if you like.