Cannot change environment at runtime

[Lasagna220]

We would like to be able to change the environment at runtime. Currently, this is not possible, as the environment.ts file gets compiled into the main.bundle.js with the rest of the code. Instead, the dist should have a separate environment.js file, so that it can be replaced at runtime.

Setting the environment at runtime is a very important feature for release pipelines. It does not make sense to build an artifact to test on a lower environment, and then have to build a new artifact for production. Being able to pass an artifact off to the higher environment provides assurance that you are releasing the same thing that you tested.

Versions.

angular-cli: 1.0.0-beta.15
node: 6.6.0
os: darwin x64

Repro steps.

ng build
Notice that the dist directory does not have a file dedicated to environment config.

[mbengali]

I was running into an issue yesterday for this reason. I wanted to change href of base tag in index.html to host Angular app in su folder when deployed to any other environments than local. But, I had to explore changes in deployment process instead of having this ability as part of Angular build.

[wirefreethought]

+1 This is a major shortcoming. We should not be embedding the environment configuration with the deployed app. The configuration should be externalizable. The internal environment object should function as little more than a stub to allow easy referencing of the set of possible config properties, but the values should be defined outside.

[wulfsberg]

Pragmatically, I am in need of this functionality as well, to configure which backend services to contact.
I am not fond of having to load this asynchronously once the whole Angular application has started, so currently, I am doing some trickery with loading an additional .js file from index.html and feeding it into a provider in the AppModule. This is already a bit roundabout, and it will turn ugly once it has to work with AoT.

[filipesilva]

I agree that changing environment at runtime is an important feature - but that doesn't mean that build-time environment is not important.

Different projects need to do different things with their environment config. At the very least, it needs to switch over Angular itself from dev to prod mode. A lot of users also need to load some extra modules. Static env files serve that purpose well.

Mind you that just because the CLI doesn't have a recommendation for this functionality it doesn't mean you can't just do it yourself. If your app truly is able to be configured at runtime, the built artefact should stay the same, thus no build-time support is needed for it.

[wulfsberg]

For those who need an easily modifiable "App config" object, this is how I ended up doing it:

• Link in an app-constants.js file in my index.html which sets a global variable called APP_CONSTANTS (a JS object with configuration data)
• In my AppModule, I have a

export function appConstantFactory(): AppConfig {
  return <AppConfig>window['APP_CONSTANTS'];
}

and make it available with a provider like this

providers: [
    {provide: APP_CONFIG, useFactory: appConstantFactory},
    ...
]

...with APP_CONFIG being an OpaqueToken, as per https://angular.io/docs/ts/latest/guide/dependency-injection.html#!#opaquetoken, and from there on, it's a fully "Angularized", injectable and mockable resource.

The slightly roundabout notation with an export'ed factory picking the variable from the window object using a string name makes it work with AoT.

So I don't consider it particularly high priority for the CLI, but I'd still like to see clever heads get together and figure out the smoothest, most elegant way to do it, in particular if it has to work with Universal or other situations without a window object to carry the globals.

[filipesilva]

Closing in favor of #3855, there is further discussion there.

[angular-automatic-lock-bot]

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