Angular-cli: Feature : javascript configuration file

[ggirou]

Bug Report or Feature Request (mark with an x)

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

Versions.

@angular/cli: 1.2.0
node: 6.10.3
os: darwin x64

Desired functionality.

I want dynamic configuration file depending on environment variables or arguments passed to angular cli.

.angular-cli.js :

module.export = {
    // ...
    "styles": [
        "styles.css",
        process.env.THEME_DIR + "/theme.css"
    ]
    // ...
};

THEME_DIR=path/to/theme ng build

or

ng build --options.theme=path/to/theme

See https://github.com/angular/angular-cli/issues/6331

[grizzm0]

You can already create multiple apps with different configurations in angular-cli.json.

Perhaps it could be improved with an "extends" key so that you don't have to duplicate every single key for every app if you simply want to change styles or scripts for example.

Example:

{
  "apps": [
    {
      "name": "app",
      "root": "src",
      "outDir": "dist",
      "assets": [
        "assets",
        "favicon.ico"
      ],
      "index": "index.html",
      "main": "main.ts",
      "polyfills": "polyfills.ts",
      "test": "test.ts",
      "tsconfig": "tsconfig.app.json",
      "prefix": "app",
      "styles": [
        "styles.scss"
      ],
      "scripts": [
        "../node_modules/hammerjs/hammer.js"
      ],
      "environmentSource": "environments/environment.ts",
      "environments": {
        "dev": "environments/environment.ts",
        "prod": "environments/environment.prod.ts"
      }
    },
    {
      "extends": "app",
      "name": "customer1",
      "styles": [
        "customer1.theme.scss"
      ],
      "environments": {
        "prod": "environments/environment.customer1.prod.ts"
      }
    }
  ]
}

[ggirou]

extends could be a solution, but I think javascript config file is more flexible and can resolve any kind of situation. Both karma and protractor are javascript files.

I currently have two themes to apply on lots of small applications. Soon I'll have 6 brands and I don't want to maintain all application configurations.
I want CI to automatically build each brand without changing .angular-cli.json when I add a new one.

Something like:

module.exports = {
    "apps": [
        {
            "name": "app",
            "assets": [
                "assets",
                { "glob": "**/*", "input": "../node_modules/my-assets/" + brand, "output": "./" }
            ],
            "styles": [
                "styles.scss",
                "../node_modules/my-themes/" + brand + ".css"
            ],
            "environments": {
                "dev": "environments/environment.ts",
                "prod": "../node_modules/my-environments/" + brand + "/environment.prod.ts"
            }
        }
    ]
};

[Brocco]

This is an interesting idea, one that we can consider, thanks.

[jaesung2061]

I'm surprised it took this long for someone to make a feature request for this. This seemed like the obvious way to go from the start.

[hansl]

Hi @ggirou, @jaesung2061,

This has been something we discussed from the start. Prior to using webpack (more than a year ago), we had a configuration file that had imperative logic, and there were a few reasons why we moved to this fixed configuration:

1. Statically analyzable; imperative logic cannot be analyzed or modified, e.g. with Schematics.
2. Predictability; changes to the CLI configuration have a direct cause and effect relation. There are no side effects, ala Gulp configuration where changing a rule can impact a seemingly unrelated rule.
3. Security; we provide a guarantee that no unwanted side effect occurs when running ng commands. Having a programmable configuration would break that guarantee and allow arbitrary code execution on even ng version.

We would rather listen to your use cases and come up with proper solutions individually than having a general solution with huge disadvantages and technical debts in the future.

In this case, you want different builds to incorporate different styles (themes). This is a reasonable use case. As @grizzm0 already stated, we support multiple applications but that's not enough. What you really want are different aspects of the same application. You want to change a few values (styles) but keep the rest of the build configuration.

We'll come up with a proper solution for this usecase, and come back to this issue in the future.

Cheers!

• Hans

[jaesung2061]

1. I think the trade-off for full control of what we need to do outweighs the cons.
2. We are developers. Let us control what we want to do with our projects. Stop putting red tape everywhere.
3. Security? Seriously? 99% of npm packages are security risks if you think about it that way. Wouldn't all Node task runners/bundlers like Grunt/Gulp/Webpack be a security risk then?

Yet another example of Angular devs walking the long way around to avoid stepping on a pebble. It's like you guys want to create the most complex and annoying solutions JUST in case some potential minor issue happens in the future.

[hansl]

1. considering the nature of problems we had before and after the switch, I stand by our decision.

2. that's why there's an eject button. There are better solution to bring developers the power they need, and the simply they want. We're working on such solutions as well.

3. Yes, Grunt/Gulp/Webpack are based on trust and are a security risk.

[angular-automatic-lock-bot[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._}