`ng serve` should support the same command line arguments as `ng build`

[hansl]

[hansl]

I'm opened to supporting a subset of ng build arguments that are commonly used, such as --aot, --sourceMap and --vendorChunk.

[cexbrayat]

It looks like ng build does not support --watch currently. But I think it would be necessary for projects with multiple applications and libraries. Because currently, when modifying a library, you have to rebuild it manually to be able the use the modification in an application. In that use case, ng build --watch could be handy, and run in the directory of the library, and ng serve in the directory of the application.

Or maybe the CLI is supposed to be smart enough and to rebuild both the library and the app when ng serve is running? But that is currently not the case with CLI 6.0.0-rc.4.

[cyrilletuzi]

While this is fixed, is there another way to enable aot during ng serve? Tried in angular.json config but can't find a way.

[sylvaindumont]

@cyrilletuzi to enable aot in ng serve, add "aot": true to your build options or one of your build configs and add "browserTarget": "<app>:build:<build-config>" to your serve config

[cyrilletuzi]

@sylvaindumont aot is already enabled by default in the build options, and serve is already using build config by default ("browserTarget": "cinemapp:build:production").

Despite this, serve is not in AOT mode (like if the CLI was overriding this option). And trying to reput the aot: true option directly in serve options to force it doesn't work either.

[filipesilva]

@cexbrayat the --watch flag is passed on to the target itself, and it is up to that targets builder to support the option. The default build target in a new project uses @angular-devkit/build-angular:browser, which supports the watch option.

But @angular-devkit/build-ng-packagr:build, which is the default builder for libraries, does not support watch mode. I've talked with @dherges (the author of ng-packagr) about this possibility but it's not something that will exist for 6.0 proper. It's something I would like in the 6.x timeframe though.

@cyrilletuzi that's odd. I just tried it myself and ng serve used AOT. Can you open an issue with a reproduction please?

[cyrilletuzi]

@filipesilva How do you check if AOT is enabled or not?

On my side, I used a syntax I know is not accepted in AOT mode (using a non exported reference with spread operator on a literal array). It effectively fail on prod build but not on serve.

[filipesilva]

When I want to be 100% sure AOT is being used I got check the main bundle. If it mentions anything about ngfactory, it means AOT is being used. You can check out the bundle content being served in your network tab in chrome dev tools.

[cyrilletuzi]

@filipesilva Verified your way, and no mention of ngfactory when serving (while there is on prod build). Same on a new empty project.

But are you sure it's working on your side? Something very strange is that serve and build options are not the same at all (like about vendor-chunks and so on), but in angular.json, we can just see the build options, and the serve options are nowhere to be seen.

It would confirm my suspicion that serve options are hard coded.

[filipesilva]

serve and build options are indeed not the same, and that is the topic of this issue. serve only contains options related to serving proper, not to building. You can check these options with ng build --help and ng serve --help.

I think I know what you're doing differently from me. You have aot: true only on the production configuration for build. But you do not have it in the base options.

When you do ng serve, it will use the base options, with no configuration. Try changing it there.

If that still doesn't work please let me know with a repro I can follow.

[cyrilletuzi]

Can you precise where are the base options exactly in angular.json?

As a general issue, there is no more autocompletion in angular.json and so it's really difficult to know where the options should be put now (had a similar problem with proxyConfig, and I didn't check yet how to do --locale now).

Thanks.

[filipesilva]

I put it here:

There's an issue for the current option discoverability problem in #10271.