Angular-cli: ng serve does not work with --base-href

[dave11mj]

Bug Report or Feature Request (mark with an x)

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

Versions.

@angular/cli: 1.1.0-beta.0
node: 6.9.5
os: darwin x64
@angular/animations: 4.1.2
@angular/common: 4.1.2
@angular/compiler: 4.1.2
@angular/core: 4.1.2
@angular/forms: 4.1.2
@angular/http: 4.1.2
@angular/language-service: 4.1.2
@angular/platform-browser: 4.1.2
@angular/platform-browser-dynamic: 4.1.2
@angular/router: 4.1.2
@angular/cli: 1.1.0-beta.0
@angular/compiler-cli: 4.1.2

Repro steps.

1. run ng new serve-with-base-href && cd serve-with-base-href/
2. run ng serve --base-href '/test/'
3. Open browser developer tools at http://localhost:4200/test/

The log given by the failure.

Desired functionality.

To be able to run ng serve under a different --base-href

Mention any other details that might be useful.

[clydin]

This is really, and unfortunately, more complicated than just adjusting the Dev server's public path. The base href adjusts all requests coming from within the index.html file; it doesn't predicate the actual location of the index.html file. I'm not sure how complicated and detailed a Dev server should actually be.

[dave11mj]

@clydin could you elaborate a bit more why it'd be a bit more complicated than setting publicPath to the specified baseHref ? I tested it out on a new application, as well as a mature application with multiple routes / nested routes / and external libraries. The only error I encountered was having a 404 on the / which was a more expected behavior given --base-href explicitly specifies where the app lives. It also doesn't seem to cause any trouble when the --base-href is ommited

[clydin]

What the --base-href option does is change the <base href=""/> value in index.html. This in turn defines the base URI for the document and is used for all relative URL within the document. The default base URI is the location of the document (index.html in this case). In the above example (ignoring the Angular router for simplicity), if the entire app (including index.html) was served from the test location, the base href would not be necessary to find the assets. The location of the index.html is completely determine by the server configuration. So from a conceptual standpoint, the base href doesn't necessarily equate to the public path. index.html could be served from the root and all the assets within /test/. Note also that the base href can technically be set to an absolute URL as well.

There is also the --deploy-url option, which webpack uses to adjust all requests for assets it manages. In regards to assets, an absolute or root-relative deploy URL will cause the base URI of the document to be unneeded/unused. A relative deploy URL will be used in combination. So if both options are used the intended public location of the assets would not be just the base URI.

[dave11mj]

I understand --base-href is meant to update <base href=""/>, however in the above example if the entire app was served from the test location it would not be using ng serve but rather ng build and a server other than webpack.

I found the bug while trying to use ng serve on App1, and ng serve --base-href '/test/' on App2 then use a load balancer proxy pass all traffic from /test/ to App2, thus, mimicking the production environment locally and leverage the speed of ng serve over ng build --watch. However, since ng serve --base-href only updated <base href=""/> all it did was break itself since it couldn't find its own bundles on either / or /test/.

Since the current behavior of ng serve --base-href '/test/' only generates a broken dev server, it makes sense to set publicPath to match baseHref so that at least we are able to visit the app under the path /test/ which to me is expected since it is where it would live in a production environment and all relative assets, urls, angular routes would work as expected.

I agree with you that a dev server shouldn't be too complicated or detailed. Which is why a small change to make ng serve --base-href be served from the specified location makes sense. That way the application out of the box will run as expected under the specified path.

It is true if that if you have absolute paths for images like /assets/hello.png it would generate a 404 but at that point to me is an understandable error and developers would have means other than the cli to fix it, unlike the bundles not loading since they are stored in memory.

[clydin]

Your proxy example should work without any code changes. The setup needs to be configured to proxy the public location /test/ to the internal location / for App2. That would also be why I would argue that the dev server is not actually broken. Automatically adjusting the internal location via the base href option or the deploy url option is not entirely obvious, may be undesirable, and, most importantly, may break existing usage.

In regards to my last paragraph, i was referring to the usage of both the base href option and the deploy url option in combination. The following are both valid configurations with very different behavior:

• --base-href "/test/" --deploy-url "assets/"
• --base-href "/test/" --deploy-url "/assets/".

I think instead of trying to guess the intentions of the developer, a --base-path option would be more appropriate. This would allow ng serve to serve the app in whatever path the developer requires or prefers.

For reference, also see these PRs (#6279, #6112) which are all trying to address a similar problem in potentially conflicting ways when accounting for base href as well.

[dave11mj]

My proxy example as is does not work on in the current release of the cli .. Since I mentioned out of the box ng serve --base-href only causes the app to break. The only way the app would run in my case was by doing ng serve --base-href '/test/' --deploy-url '/' but then proxy passing would not work since App2 would expect bundles to live under / ..

https://github.com/angular/angular-cli/pull/6279 was definitely one of the things I tried and that PR would have fixed. As for https://github.com/angular/angular-cli/pull/6112 it seems to be setting publicPath to be the same as --deploy-url so it would definitely conflict with setting it to --base-hef ..

I agree a --base-path option would be nice to have, although seems would also conflict with --deploy-url. It would be nice to have some documentation on how to ng serve and application under a different path.

[dave11mj]

@clydin do you know if there is something I am missing about https://github.com/angular/angular-cli/pull/6112 ? I double checked my logs to make sure to have I have that commit, and trying out ng serve --deploy-url '/test/' and ng serve --deploy-url '/test/' --base-href '/test/' but all I get are the same bundles not found error, even though publicPath should be set by that commit.

[smoke]

6112 Fixes exactly the issue reported here.

[angular-automatic-lock-bot[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._}