Echo JS 0.11.0

dotenv is *NOT* meant to be used this way...

Generally speaking, do *NOT* commit your environment configurations (other than local development) to source control, you do *NOT* want variance in your configuration files, this is a deployment issue.

What you should do, is add `.env` to your .gitignore file so it doesn't get committed.  You may want to add a `.env.dev.env` to source control with typical local settings.  The dev env file should have a comment that you should copy it to a plain `.env` file for local development.  You should also consider having fallback options in your configuration module, that represents the dev or production defaults as much as reasonable.  ONLY load `.env` not ENVIRONMENT.env

Advice, load the .env file before loading any other modules, do it all synchronously, or an async load of your modules after environment and configuration are loaded.  I would advise searching upward at least 2-3 directories for the .env then change your working directory to where the .env file is... for a static (non-container) deployment, this allows you to setup your .env in a parent directory from your application, and relative paths should work properly.

For containerized (docker) deployments, you should set the environment as part of your start/deployment model.  Kubernetes, Dokku and other orchestration environments have options for this, you shouldn't deploy a .env file inside a container, and generally it should be mostly for development and/or static deployments.

Aside: you may, if using CI/CD for static deployments, want to use a `.env.template.env` file for transformation as part of your deployment model.