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/environment.dev.ts and /config/environment.prod.ts 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/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

[serhiisol]

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

[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.