Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ng serve should support the same command line arguments as ng build #10304

Closed
hansl opened this issue Apr 12, 2018 · 16 comments
Closed

ng serve should support the same command line arguments as ng build #10304

hansl opened this issue Apr 12, 2018 · 16 comments
Assignees
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Milestone

Comments

@hansl
Copy link
Contributor

hansl commented Apr 12, 2018

No description provided.

@hansl hansl added the P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent label Apr 12, 2018
@hansl hansl added this to the v6.0.0 milestone Apr 12, 2018
@hansl
Copy link
Contributor Author

hansl commented Apr 12, 2018

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

@filipesilva filipesilva self-assigned this Apr 13, 2018
@cexbrayat
Copy link
Member

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
Copy link
Contributor

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
Copy link

@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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

cyrilletuzi commented Apr 16, 2018

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
Copy link
Contributor

I put it here:

image

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

@cyrilletuzi
Copy link
Contributor

cyrilletuzi commented Apr 16, 2018

Thanks, it works. Bonus question: initial plans were to enable AOT by default for v5. It's still not ready for v6, or the idea has been dropped?

@filipesilva
Copy link
Contributor

filipesilva commented Apr 16, 2018

The reasons we didn't enable it by default in v5 was the scalability of it. AOT compilation did not scale very well because templates were always recompiled. It was fine by default on small and medium projects, but not in large or very large ones.

The idea hasn't been dropped though, and the compiler team is looking at some architectural solutions to this which look promising. Some of it might might come up during the 6.x lifecycle but would not be the default.

@cyrilletuzi
Copy link
Contributor

Shouldn't locale options (like i18n-locale) be supported on serve too?

@hansl hansl assigned hansl and unassigned filipesilva Apr 17, 2018
hansl added a commit to hansl/devkit that referenced this issue Apr 18, 2018
…ev-server

This will allow people to override some flags from a base browser target, either from
the command line or from their serve directly.

The options chosen are kinda arbitrary. I simply looked at what made sense.

Fix angular/angular-cli#10304
hansl added a commit to hansl/devkit that referenced this issue Apr 18, 2018
…ev-server

This will allow people to override some flags from a base browser target, either from
the command line or from their serve directly.

The options chosen are kinda arbitrary. I simply looked at what made sense.

Fix angular/angular-cli#10304
hansl added a commit to hansl/devkit that referenced this issue Apr 18, 2018
…ev-server

This will allow people to override some flags from a base browser target, either from
the command line or from their serve directly.

The options chosen are kinda arbitrary. I simply looked at what made sense.

Fix angular/angular-cli#10304
hansl added a commit to hansl/devkit that referenced this issue Apr 18, 2018
…ev-server

This will allow people to override some flags from a base browser target, either from
the command line or from their serve directly.

The options chosen are kinda arbitrary. I simply looked at what made sense.

Fix angular/angular-cli#10304
hansl added a commit to angular/devkit that referenced this issue Apr 18, 2018
…ev-server

This will allow people to override some flags from a base browser target, either from
the command line or from their serve directly.

The options chosen are kinda arbitrary. I simply looked at what made sense.

Fix angular/angular-cli#10304
hansl added a commit that referenced this issue Jun 6, 2018
…ev-server

This will allow people to override some flags from a base browser target, either from
the command line or from their serve directly.

The options chosen are kinda arbitrary. I simply looked at what made sense.

Fix #10304
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Projects
None yet
Development

No branches or pull requests

5 participants