Provide Angular build context to external tool configuration files

Empieza revisando cómo ng build lee las opciones y configuraciones de build de angular.json y, después, lee la discusión relacionada sobre PurgeCSS en #20015. El issue necesita una decisión entre los enfoques propuestos basados en variables de entorno antes de que pueda comenzar la implementación; se considerará terminado cuando haya un diseño acordado, una semántica de configuración documentada y cobertura para la combinación de configuraciones y el comportamiento de la plataforma.

🚀 Feature request

Command (mark with an x)

• build

Description

Spin off from PurgeCSS discussion in #20015.

It would be nice for external tool configuration files (like Tailwind) to have some knowledge about the Angular build context in order to conditionalize their configurations. This could allow ng build --configuration production to change the config used by other tools and affect their builds as well. This allows other tools in a project to be more intelligent about the intent of a build and do what the user expects.

Describe the solution you'd like

There are a couple possible implementations of this.

1. Set an environment variable like NG_BUILD_CONFIGS="foo,bar,baz". Then config files could do something like:

const enableOptimizations = process.env['NG_BUILD_CONFIGS'].split(',').includes('production');

This would decouple the Angular CLI from any specific tools and allow the individual tool configs to define the semantics for each configuration. Similarly, the semantics for each configuration are also defined directly in the tool's config file rather than angular.json. That seems weird to me, but arguably it's a benefit so 🤷‍♂️. It also means that the config needs some knowledge of Angular, which isn't too bad considering its in the config, not the tool library, but this can still be undesirable.

2. Add an env option in angular.json. Each configuration in the angular.json file could include an env map that looks like:

{
  "projects": {
    "my-project": {
      "architect": {
        "build": {
          "options": {
            "env": {
              "MY_BUILD_ENV": "development",
            },
          },
        },
        "configurations": {
          "production": {
            "env": {
              "MY_BUILD_ENV": "production",
            },
          },
        },
      },
    },
  },
}

The Angular CLI would parse and set the relevant environment variables during a build. Then tool configs could look for the project-specific environment variables like so:

const enableOptimizations = process.env['MY_BUILD_ENV'] === 'production';

This would still give users full control over the semantics of any given environment variable and they can choose its value on a per-configuration basis. The challenges here include merging multiple configuration environment variables which might conflict and that this environment would apply to all tools used by the Angular CLI. Users might also break something by setting a variable they probably shouldn't (such as PATH or other system variables) and breaking the CLI.

3. Just have users set the environment variable on the command line:

MY_BUILD_ENV="production" ng build --configuration production

Then use that variable in the tool config just like previously:

const enableOptimizations = process.env['MY_BUILD_ENV'] === 'production';

This requires no effort on the Angular CLI side and users can do this today. The downside here is that it requires special knowledge of how to build a particular app. A new developer would reasonably expect ng build --configuration production to do everything it needs to, and then be surprised something didn't optimize because they didn't set MY_BUILD_ENV="production". Projects could wrap such a command into an npm run build:prod which sets the variable, but not everyone will use it. This is also a cross platform issue, as I don't think there is a Unix and Windows compatible way of doing this (see this question), so supporting both environment for build is more hassle for the user.

There are likely other possible implementations that have their own trade offs. We'll need to discuss this more and come to a decision on how to move forward here.