build(aio): add support for faster, unoptimized serve

[gkalpak]

PR Checklist

• The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Build related changes

What is the current behavior?

When running yarn start and yarn serve-and-sync, we are usually more interested in faster re-build times than optimized builds. This was also the behavior, before upgrading to @angular/cli@6 (fc5af69).

What is the new behavior?

This commit introduces a new configuration (fast), which is used by yarn start and yarn serve-and-sync to restore the faster, unoptimized builds.
Other commands, such as ng serve and ng e2e, remain unchanged (using slower, optimized builds).

Does this PR introduce a breaking change?

[ ] Yes
[x] No

[mary-poppins]

You can preview 3915d69 at https://pr23569-3915d69.ngbuilds.io/.

[ngbot]

I see that you just added the PR action: merge label, but the following checks are still failing:
     forbidden label detected: PR action: review
     status "continuous-integration/travis-ci/pr" is failing

If you want your PR to be merged, it has to pass all the CI checks.

If you can't get the PR to a green state due to flakes or broken master, please try rebasing to master and/or restarting the CI job. If that fails and you believe that the issue is not due to your change, please contact the caretaker and ask for help.

[IgorMinar]

I was wondering about this - it seems that we no longer have the capability in cli to have a matrix of environment vs configuration - I'm not sure if this was intentional but it seems like step backwards in terms of flexibility. @hansl @filipesilva can you provide some insights? are we missing anything?

[hansl]

@IgorMinar environments in 1.7 was only about file replacement, while target was optimization level. Now that all flags are part of the build configuration, they’ve been replaced by configurations for both (and you can use values on the command line, like —optimization=true instead of —target=prod).

It seems to me that your default options should be non optimized and use a different configuration for different levels of optimization.

[gkalpak]

I see two problems:

1. It is not possible to share a configuration (that is different than the default) with several environments. For example, we hav three different production environments: stable (for the currently stable version; e.g. 5.x), next (for the @next version; e.g. 6.x/master), and archive (for older versions; 3.x, 4.x, etc.). We could repeat the options in each one, but this is tedious and can easily get out-of-sync.

2. AFAICT, the flags only apply to build, not other commands, such as serve. So, if we want to be able to serve optimized/unoptimized versions for different purposes, we need to have two different configurations.

[hansl]

1. We are thinking of adding extends as a keyword to entend targets and configurations, so that would solve it. 2. Serve has some more options now, including optimization and aot. It overrides the browser target option. Hope this helps!

…

On Apr 27, 2018, 08:19 -0700, George Kalpakas ***@***.***>, wrote: I see two problems: 1. > It is not possible to share a configuration (that is different than the default) with several environments. For example, we hav three different production environments: stable (for the currently stable version; e.g. 5.x), next (for the @next version; e.g. 6.x/master), and archive (for older versions; 3.x, 4.x, etc.). We could repeat the options in each one, but this is tedious and can easily get out-of-sync. 2. > AFAICT, the flags only apply to build, not other commands, such as serve. So, if we want to be able to serve optimized/unoptimized versions for different purposes, we need to have two different configurations. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[gkalpak]

Great to hear. Extending would be awesome indeed. Thx!

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