The current model for environment variables is to have 3 places for files:
/src/environment.ts/config/environment.dev.ts and /config/environment.prod.tsdist/ folder./dist/environment.jsFollow this scenario ... we need an env variable to point to a web url for our APIs. So we create a
export const environment {
  url: '/api/foo`
};
and we put it in /src/environment.ts. We then import it with import { environment } from './environment. VS Code is happy (as is any tsc compiler command). 
Now we run ng serve and browse to the app, and we see an error in the console about how it doesnt know what url is. Oops, we didnt put this in the config/environment.dev.ts (nor prod) files. OK, so we go do that and now we can run and serve smoothly.
Now ... we add a new env for showDebugMessages: true. We set it to true for dev and false for prod. We recall that we need to do this in the /config/environment.*.ts files so we feel we are good. But we forgot we also need to put the same setting in the /src/environment.ts. It is not used ... but we need something there. Do we out false or true for this new setting? It doesn't matter because we are not using it.
export const environment {
  url: '/api/foo`,
  showDebugMessages: true
};
My point here is that it can be confusing on how to do this and not make a mistake.
Are there any thoughts on how to prescribe this? Or how to make it easier? Have you considered an interface?
My Env:
$ ng -v
angular-cli: 1.0.0-beta.5
node: 4.2.3
os: darwin x64
cc @spboyer
Posted on how to use and the drawbacks here: https://tattoocoder.com/angular-cli-using-the-environment-option/
interface, at least in the current folder structure is not a good workflow. The interface would either need to be at the base root of the project or in a place where referencing it doesn't make sense.
fwiw, we get by just fine without environment.ts. We only have/use the dev/prod copies.
Also it would be great if we could make parent configuration, which config/environment.*.ts might extend, for instance:
_config/environment.base.ts_
export var environment = {
    API_BASE_URL: "http://example.com/api"
}
_config/environment.dev.ts_
import {extend} from 'lodash';
import {base} from './environment.base';
export var environment = extend(base, {
    dev: true
});
currently EmberCli base project reads and compiles only specific file based on version (prod or dev)
_angular-cli/lib/broccoli/environment.js_
  // Load the content of the environment file.
  const filePath = path.join(project.root, `config/environment.${env}.ts`);
  const source = fs.readFileSync(filePath, 'utf-8');
  const result = ts.transpile(source, {
    target: ts.ScriptTarget.ES5,
    module: ts.ModuleKind.CommonJs
  });
So what I'm saying is that you can't import something and extend it later
@SergeySolonko this doesn't require special angular-cli support, i believe. Simply put environment.base.ts in your project's top-level src tree (not in config), and your extend() example "should" (i believe) work as-is. Except that... in 1.0.0-beta.5 environment.xxx.ts cannot reference ANY external symbols (e.g. window)  and cannot import project-level includes (see ticket #833). Once that ticket is resolved, your feature request should come "for free."
@sgbeal Ok, got it
Hi guys,
Do you know why I can't get it to work with my unit tests ? #1419 
// from 12factor
such as the development, test, and production environments in Rails. 
This method does not scale cleanly: as more deploys of the app are created, 
new environment names are necessary, such as staging or qa.
As the project grows further, developers may add their own special environments 
like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle
just my 2 cent
P.S: I've created env addon https://github.com/antonybudianto/angular-cli-env, for those interested. it's dotenv inspired
I believe this is resolved with the webpack version of CLI
@randyaa I agree. Originally the functionality was more confusing and less documented than it is now.
Documentation can be found https://github.com/angular/angular-cli#build-targets-and-environment-files, and now the third file is not needed.
@filipesilva
I would like to import environment to the app.components.ts like
import { environment } from './environment';
therefore I have to create src/app/environment.ts. Why the value of environment.production is still false when I run  ng serve --environment=prod ? I am using angular-cli: 1.0.0-beta.19-3
@matodrobec Hi, you can create workaround for your case, just simply add index.ts file in environments folder with content:
export { environment } from './environment';
and then you can easily import environment through index.ts like so
In app.component.ts
import {environment} from '../environments';
You have to use '../' because environments folder is in the folder one level up
I followed the above process, But I got this error --> _src/app/app.component.ts (17,22): Cannot find namespace 'environment'_
I am really surprised how hard it is to find a simple tutorial/solution for cmd webpack -p --env.prd true and an environment configuration being available in an Angular2 Typescript app, I developed a very simple solution https://github.com/Sweetog/yet-another-angular2-boilerplate
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
Also it would be great if we could make parent configuration, which
config/environment.*.tsmight extend, for instance:_config/environment.base.ts_
_config/environment.dev.ts_
currently EmberCli base project reads and compiles only specific file based on version (prod or dev)
_angular-cli/lib/broccoli/environment.js_
So what I'm saying is that you can't import something and extend it later