1

It's a lot of references to dotenv library to use when you want to specify env variables. But why? I can just specify my var in a file like this:

var dev = { } var prod = { } var config = null; if (process.env.NODE_ENV === 'production') { config = prod } else { config = dev } exports.config = config

and assign my var in npm srcipts, like this:

"scripts": { "start": "NODE_ENV=dev node bin/dev", "production": "NODE_ENV=production node bin/production" }

Is my way not secure? Why is dotenv way recommended? Why should I create .env files instead my config.js?

Improve this question
3
  • .dotEnv isn't secure either. But that's not the point. You should exclude .env from your git repo so no one else can inadvertently see your values. Then when you deploy to a server you add it to the environment files of your server. Commented Oct 27, 2018 at 17:13
  • Yes, I agree! But I can also do the same thing with my config.js file. I can .gitignore this file from public and then add it to deploy flow... Why .dotEnv is so popular way? Commented Oct 27, 2018 at 17:24
  • 1
    Keeps your environment variables together. Using a .js file is fine but soon or later someone (teams can get large) will end up committing a value they shouldn't. It's usually more useful for API keys and SECRET's Commented Oct 27, 2018 at 17:30

2 Answers 2

Reset to default
1

  • Environment variables is the commonly assumed way to configure the behaviour of a program, across all programming languages. It is also supported out-of-the box in most CI/CD tools, as well working really well with the command line.

  • In your example, you assume that the complete config of the prd environment will be stored in the config, including db password etc. It is not considered secure to store any secrets in source code.

  • The.env file is a common utility for bundling environment variables. It is really is easy to create a .gitignore file with this pattern that prevents it from ever being committed so that configuration stays local. Note that the consumer of the package doesn't have to use a .env file but could also have global/local environment vars where the script is ran. Development solid and not so prone to mistakes.

  • Syntax simplicity. instead of creating an ad-hoc source code file containing configuration, with more complex syntax than key=value and less common to understand.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

@Nastro, I'll point a little and simple different approach.

Develop your application 100% agnostic of an environment. In other words, keep away *from versioning files within your code or lots of if assigning different values to globals, sessions attributes and etc.

Favor your environments with the due env vars and values. Usually, the most strategic or special environments will be protected against unwanted access(production, staging and etc), so your secret values will be unreachable.

A single db_password = process.env.DB_PASS will be reusable for any existing and future environment you or your team creates.

This is a simple, yet effective approach, but demands a minimal control over your environment and hosts.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.