incremental builds without watch mode

[fr0]

Bug Report or Feature Request (mark with an x)

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

Versions.

@angular/cli: 1.3.0 (e)
node: 6.10.2
os: darwin x64
@angular/common: 4.3.5
@angular/compiler: 4.3.5
@angular/core: 4.3.5
@angular/forms: 4.3.5
@angular/http: 4.3.5
@angular/platform-browser: 4.3.5
@angular/platform-browser-dynamic: 4.3.5
@angular/router: 4.3.5
@angular/cli: 1.3.0
@angular/compiler-cli: 4.3.5

Desired functionality.

I'd like ng build to be just as fast on rebuilds as ng watch is.
In other words, is it possible to tell ng build to keep (on disk) the same intermediate data that ng watch does to make recompiles fast?

Mention any other details that might be useful.

We use a GNUmakefile, and I've plumbed ng build into that makefile. For most of my team members, it's easier just to tell them to type make (which also builds our server-side) rather than teach them how to use the ngtools and to ask them to have a watch process running in the background.

[fr0]

Webpack has a plugin called DllPlugin that enables this. Is this plugin compatible with @ngtools/webpack and the Angular AoT complier?

[filipesilva]

Heya, regarding DllPlugin, there are technical problems that prevent us from using it (see #4565 for more information).

I'm not sure what you mean by ng watch though. Are you talking about ng serve?

The approach you described could be done through https://github.com/mzgoddard/hard-source-webpack-plugin. But this is not something I think is a good idea, because there's a lot of things that can affect builds and there's really no guarantee the intermediate the cache is still valid between sessions. Changes in webpack/cli/plugin versions can make different builds, and so can code changes.

I'd expect ng build --watch to be about as fast for rebuilds as ng serve though, the only real difference being writing files on disk. Each time ng build or ng serve is ran they will take the startup time though, as a brand new build needs to be created.

[fr0]

Thanks for the response.

I have found that ng build --watch is quite fast -- that's not the issue. The problem is that ng build without watch is 1 or 2 orders of magnitude slower than rebuilds via ng build --watch or ng serve.

On an example repo with very little code, rebuilds under watch mode take 0.5 sec - 3 sec (depending on whether AoT is enabled), and ng build (without watch) takes 20 - 30 seconds on Mac OS, or 40 - 45 seconds on Windows. The DllPlugin seemed like a nice solution to that.

Regarding the hard-source-webpack-plugin, I tried it and it did shave several seconds off of my build times, but with some unreliability (builds would occasionally fail for no discernible reason), so I gave up on it.

I hope that your team can make progress on #4565 -- in the meantime, it sounds like that issue has already captured my use case and this one can be closed as a duplicate, if you wish. Thanks again!

[filipesilva]

Actually, #4565 would only really affect rebuilds. The only thing in webpackland that can cut down the initial build time is the hard source plugin, but it is sensitive to the problems we discussed and you've experienced.

[filipesilva]

Also relevant, this problem is getting some traction as an issue in webpack proper: webpack/webpack#250

/cc @intellix

[mgechev]

Once webpack 5 is out, or we introduce Bazel support we'll have this feature. It's definitely on the roadmap. The CLI, however, is not the correct place to follow the progress.

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