4 ms·

I personally don't feel the same, I have no idea why you'd want a typed environment variable setup. And I find they work great. I don't see any problem with 4

I personally don't feel the same, I have no idea why you'd want a typed environment variable setup. And I find they work great. I don't see any problem with 4 different things using it. The point of it is basic, rather then VARIABLE=WHATEVER you just copy and paste a .env and it picks it up. But you can also just use regular environment variables if you want.

calibas 3y ago
> I have no idea why you'd want a typed environment variable setup. Because you want to know what type your variables are? Of course, in this case you do know, they're strings.
- poisonborz 3y ago
  You can trivially write a schema file and a method that checks the existence and type of the env var on startup. I actually did on some projects. It's not needed most of the time so I could only see this as an npm module.
  - maccard 3y ago
    Manually writing reliable file IO, serialisation and schema validation on every project is a colossal waste of time effort and energy collectively. I for one am glad that with 2 lines of code I get type safe environment variables with config overrides in go, and never have to think about it ever again.
    - poisonborz 3y ago
      Colossal waste? - have a .json with format [{ name: AUTH_TOKEN, type: String }] (you can add extras like regex match etc) - have a method that goes through all items on startup and checks process.env existence plus the type. - use this method as a getter method based on name - search replace all other process.env usage and disable it via linting so that no one can get around the restriction voila. Oooor use these libs from other people who had the same idea (I just found them as well) https://www.npmjs.com/package/envalid https://www.npmjs.com/package/envalid https://www.npmjs.com/package/env-vars-validator https://www.npmjs.com/package/env-vars-validator

4 ms·

I personally don't feel the same, I have no idea why you'd want a typed environment variable setup. And I find they work great. I don't see any problem with 4

by dubcanada 3y ago

calibas 3y ago
> I have no idea why you'd want a typed environment variable setup. Because you want to know what type your variables are? Of course, in this case you do know, they're strings.
- poisonborz 3y ago
  You can trivially write a schema file and a method that checks the existence and type of the env var on startup. I actually did on some projects. It's not needed most of the time so I could only see this as an npm module.
  - maccard 3y ago
    Manually writing reliable file IO, serialisation and schema validation on every project is a colossal waste of time effort and energy collectively. I for one am glad that with 2 lines of code I get type safe environment variables with config overrides in go, and never have to think about it ever again.
    - poisonborz 3y ago
      Colossal waste? - have a .json with format [{ name: AUTH_TOKEN, type: String }] (you can add extras like regex match etc) - have a method that goes through all items on startup and checks process.env existence plus the type. - use this method as a getter method based on name - search replace all other process.env usage and disable it via linting so that no one can get around the restriction voila. Oooor use these libs from other people who had the same idea (I just found them as well) https://www.npmjs.com/package/envalid https://www.npmjs.com/package/envalid https://www.npmjs.com/package/env-vars-validator https://www.npmjs.com/package/env-vars-validator