Solvedangular cli Multiple environment.ts are confusing

The current model for environment variables is to have 3 places for files:

  1. /src/environment.ts
    This is here so when we type in VS Code or our favorite editor we get intellisense. it is not used for a build
  2. /config/ and /config/
    This is where we put our env settings for the different environments. It is copied to the dist/ folder.
  3. /dist/environment.js
    This is the one that gets run, we do not edit this one.

Follow 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/ (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

16 Answers

✔️Accepted Answer

Also it would be great if we could make parent configuration, which config/environment.*.ts might extend, for instance:


export var environment = {
    API_BASE_URL: ""


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)


  // 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

Other Answers:

Posted on how to use and the drawbacks here:

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.

@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

More Issues: