Parallelize ES5 & ES2015 builds

🚀 Feature request

Having a possibility to serve ES2015 is awesome! But, the build time was increased nearly twice because now instead of one build we have two.

Please provide ways to deal with this.

Command (mark with an x)

- [ ] new
- [x] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Description

The build time has significantly increased because ES5 and ES2015 builds are sequential.

Is there some reasoning behind this? Would it be faster to run them in parallel (at least with some explicit settings)?

Describe the solution you’d like

1. Parallelize those builds by default (or with special CLI flag probably)
2. Add a special CLI flag / configuration in angular.json that allows to build es5 and es2015 separately on different runners. This would be cool for CI because the builds could run on different physical devices (at least for CI tools where the dist folder gets mounted, e.g. Drone CI). This could cause problems with sharing the same dist directory (that is cleared before build), so this needs to be somehow resolved. However, if the option 1 is in place, I guess, this could be omitted

Describe alternatives you’ve considered

Disabling es2015 build 😦

[clydin]

Angular CLI 8.3 and above no longer perform two full builds to support differential loading. Only an ES module compatible build is now created and then down-leveled directly to ES5. This can greatly reduce the time taken to perform a build especially for larger applications.

[filipesilva]

There are some concerns about progress reporting but they are minor.

As far as the individual build steps go, they are mostly parallelizable. Almost all compilation steps inside webpack run in the single thread.

There are three very expensive steps that only happen in prod builds: build-optimizer, module concatenation, and minification. Of these, only minification uses parallel processing.

But parallelizing things that themselves try to parallelize does not compose well. At some point the minification steps of both builds would look at the total available CPUs and say “right, so let’s use them all”. The best case scenario there is that both just bottleneck and get slower.

That’d be the end of it if CPU was the only relevant shared resource. But there is another one: memory. And that one is less easy to manage. Memory management is Node is mostly static, you define a maximum and there it goes. In Node 12 it figures out the maximum at the start, but that’s still static from there on.

The really bad case is that at some point there are 2 minification processes that are processing a really big chunk (like main) and one/both will hit the memory and crash. To prevent that we’d have to ensure no two builds try to minify at the same time, or that minification doesn’t use parallelism.

But I’m not sure that’d be such a great win insofar as build time. I can’t imagine it would reduce it to half. Parallelization rarely does.

As an aside, we should figure out why the build time in webpack isn’t the full time. It really should be in your first screenshot.