Use the Webpack EnvironmentPlugin for all build targets, and allow configuration through .angular-cli.json

[dopry]

Bug Report or Feature Request (mark with an x)

- [ ] bug report -> please search issues before submitting
- [X ] feature request

Versions.

@angular/cli: 1.3.2
node: 8.2.1
os: win32 x64
@angular/animations: 4.3.6
@angular/common: 4.3.6
@angular/compiler: 4.3.6
@angular/core: 4.3.6
@angular/forms: 4.3.6
@angular/http: 4.3.6
@angular/platform-browser: 4.3.6
@angular/platform-browser-dynamic: 4.3.6
@angular/router: 4.3.6
@angular/cli: 1.3.2
@angular/compiler-cli: 4.3.6
@angular/language-service: 4.3.6

Desired functionality.

It would be nice if the WebPack config implemented the EnvironmentPlugin for all build targets and users could specify environment variables and their default config in the .angular-cli.json.

The EnvironmentPlugin is currently used for production builds to make process.env.NODE_ENV from build time at run time.

The 12 Factors Config pattern recommends that all config lives in environment variables and considers storing environment/config in files or using named groups like NODE_ENV=production anti-patterns. For our client side applications we keep config in environment variables on our build servers, and build packages for deployment. For our server side applications we set environment variables in the shell. This patterns works extremely well with a lot cloud build serivces, PAAS providers, and containerization.

See: #4318 for similar requests.

Ideally we could add the following to .angular-cli.json

{
   "apps": [
    {
      "root": "src",
      "outDir": "dist",
     ...
      "config": {
        "NODE_ENV": "production",
        "API_URL": "http://localhost.com:3000",
        ...
      }
    }
  ]
}

The could be used in parallel with the existing /environments folder giving users the option to pick their preferred approach, although I would personally lobby to deprecate /environments over time.

[clydin]

process.env.NODE_ENV === 'production' will hold true in a production build (i.e., --target production/--prod).
Note that neither process, env, nor NODE_ENV will exist in a development target build.

[dopry]

@clydin is process.env.NODE_ENV available at runtime after a production build? Then EnvironmentPlugin makes the process.env.* at build time available at run time.

[clydin]

Yes. The plugin is currently used for this purpose (see here).

[dopry]

@clydin, I search for that and didn't find it. hmm... I guess my feature request is to always run the EnvironmentPlugin and to be able to specify the variables it picks up in .angular-cli.json, along the lines of

{ 
  "apps": 
  [ 
    { 
      "config": 
      { 
        "ENV_VAR": "default value"
      }
    }
  ] 
}

does that sound like a decent revision? If so I'll modify the issue to reflect that.

[MartinNuc]

This could relate to #4318

[dopry]

@MartinNuc, #4318 would be exactly what this feature request would address. If we can get some agreement on how to implement I might be able to find the time.

[filipesilva]

Marking as duplicate of #4318 to keep the discussion in a single place.

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