Command serve feature: Allow content to be served from virtual host path

[suau]

Feature: Allow content to be served from virtual host path e.g. http://example.com/admin/

Fix #3010

[Meligy]

The ng build command has an option called --base-href (-bh for short).

Would it make sense for the ng serve implementation to make use of the same name parameter?

[suau]

@Meligy yes, that sounds very reasonable, since the base-href needs to be changed as well to make virtual host path work properly.

[filipesilva]

Hi, can you first open the issue that the PR is trying to address? You seem to be trying to do something like #2276, but since you're only doing that in serve it would never make a build that would work with a public path.

[Meligy]

@filipesilva the build is taken care of by --base-href flag to ng build. This one is trying to mimic the --base-href behaviour in serve.

[Meligy]

@suau can you please fix the merge conflict?

[suau]

@Meligy done, I also renamed the param to --base-href as you suggested. This should clear up some of the confusion. Additionally I added the necessary config for base-href-webpack-plugin to pick it up and change the index.html <base href...> tag accordingly.

@filipesilva this option is used for local development only and used to emulate --base-href on a local environment.
Just as an example: For local development I'm running a docker-compose setup with a ng2-frontend, ng2-admin-frontend, database, api server and loadbalancer (path based routing) component each in its own container. In order to have ng2-frontend and ng2-admin-frontend to play nice together behind the load-balancer, one of them needs to run on a virtual host path.

[filipesilva]

Ok I see what you're trying to do. Can you add a new test in https://github.com/angular/angular-cli/blob/master/tests/e2e/tests/test/e2e.ts to make sure it's correctly served?

[suau]

@filipesilva I'm having some issues writing a reasonable e2e test for this:

• I've added another naive serve and ng e2e cycle to https://github.com/angular/angular-cli/blob/master/tests/e2e/tests/test/e2e.ts, however I expected it to fail, as the generated test-project/e2e/app.po.ts explicitly navigates to the root '/'. To my surprise it still passes and I can't figure out why (Pushed it for discussion).
  Manually setting up a new angular-cli project will fail ng e2e as expected.
• As mentioned above test-project/e2e/app.po.ts explicitly navigates to the root '/', which makes writing a reasonable e2e test hard, either I'd need go into app.po.ts and change that or go into protractor.conf.js and change the baseUrl (and additionally change navigation to be relative to that). Both methods would be poking around in generated project files, which feels somewhat wrong.
  The probably cleanest solution would be to allow ng e2e to accept a a --base-href argument as well and rewrite protractor.conf.js before passing it to protractor, however this would break all host-relative e2e tests (all with browser.navigate('/..' that start with a /)

I'm not sure what to do to write a useful e2e test. Input would be appreciated.

[filipesilva]

Very weird that the test is passing I tried it locally and could see the app being served correctly:

And the test failing:

kamik@T460p MINGW64 /D/sandbox/master-proj (master)
$ ng e2e
(...)
Spec started
F
  master-proj App
    × should display message saying app works
      - Failed: Angular could not be found on the page http://localhost:4200/ : retries looking for angular exceeded
(...)

I can also see in travis that it did run the test and reported positive... https://travis-ci.org/angular/angular-cli/jobs/177204174#L3929-L3964

Tbh I don't know why it's passing but it definitely shouldn't, otherwise we can't test the feature.

Do me a favor, edit the test to look like this (adding a fail expectancy and editing the e2e test) and I'll investigate further:

import {ng, killAllProcesses} from '../../utils/process';
import {expectToFail} from '../../utils/utils';
import {replaceInFile } from '../../utils/fs';
import {ngServe} from '../../utils/project';


function _runServeAndE2e(...args: string[]) {
  return ngServe(...args)
    .then(() => ng('e2e'))
    .then(() => killAllProcesses(), (err: any) => {
      killAllProcesses();
      throw err;
    });
}

export default function() {
  // This is supposed to fail without serving first...
  return expectToFail(() => ng('e2e'))
    // These should work.
    .then(() => _runServeAndE2e())
    .then(() => _runServeAndE2e('--prod'))
    .then(() => _runServeAndE2e('--aot'))
    .then(() => _runServeAndE2e('--aot', '--prod'))
    // this should fail because we haven't changed the e2e test yet
    .then(() => expectToFail(() => _runServeAndE2e('--base-href /test-base-href/')))
    .then(() => replaceInFile('e2e/app.po.ts',
                              'browser.get(\'/\');',
                              'browser.get(\'/test-base-href/\');'))
    // now it should pass
    .then(() => _runServeAndE2e('--base-href /test-base-href/'));
}

[suau]

@filipesilva For a second I thought it's a OS X / Windows command line escaping issue, but since AppVeyor fails now too, it probably isn't. Can you confirm that the first relevant test fails on windows too ? (the one where it's expected to fail, but succeeded)

[filipesilva]

Superseded by #3285, as it is more complete.

[mischkl]

Please correct me if I'm wrong but it seems like #3285 still doesn't solve the problem described here.

All I want is to have my "ng serve" automatically serve my app from /my-app-path/ instead of /, and have my "base href" in the index.html set accordingly. This is useful so that I can ensure that my app's base url is the same in my local dev-server environment as it is when the app is deployed in production.

I tried adding "deployUrl": "my-app-path/" and "deployUrl": "/my-app-path/" to the apps[0] object in .angular-cli.json, but to no avail. I also tried running "ng serve --base-href /my-app-path/", also to no avail. In both cases, as well as when combining the two options, the browser gives me the error "GET http://localhost:4200/my-app-path/main.bundle.js 404 (Not Found)", for all of the bundles. This is using the newest versions of Angular-CLI, Angular and TypeScript.

If there's a way to do what I want with the current tools, I'd be very grateful for an explanation. If not, then it seems this issue should be re-opened.

Furthermore, it seems a bit odd to me that the "deployUrl" option is available from the command line and the .angular-cli.json file, while as far as I can tell the "base-href" is only available from the command line. As mentioned in #3010, it would be nice to be able to configure a default (i.e. within .angular-cli.json) instead of having to specify it via the command line every time.

Finally, the documentation for both of these options (deployUrl and base-href) is pretty much non-existent at the moment - hence my trials and tribulations, I guess. It would be great if there were some clear explanations on how to use them.

[mischkl]

OK, after even more trial and error I discovered that the "deployUrl" option in .angular-cli.json seems to do exactly nothing when running ng serve. If I specify it on the command line with "ng serve --deploy-url=my-app-path/" it results in the browser trying to resolve the bundles at that path, but failing. If I specify both the base-href and the deploy-url options, it results in trying to load the bundles from a doubled path, e.g. "http://localhost:4200/my-app-path/my-app-path/main.bundle.js", which again (of course) doesn't work.

Am I doing something wrong here or has anyone else come across similar issues before? I'm just about ready to tear my hair out!

[changLiuUNSW]

Hi, @mischkl
Currently the deployUrl does not support ng serve

[filipesilva]

I just merged #6112, that should fix that.

[mischkl]

Great news! Thanks @scriste-sv + @filipesilva :)

[chatumoh]

I tried doing this way ng serve --deploy-url /deployPath/ --base-href /deployPath/ but still i am getting 404 for http://localhost:4200/deployPath/inline.bundle.js AM i missing something ?

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