add support for publicPath option in webpack

[Mischi]

Hi all,

this PR tries to add the publicPath option for webpack.
I have not figured out how to test this feature yet? Would be happy for any suggestions though 😃

Personally i would like to use this feature to easily integrate angular-cli based projects into ASP.NET MVC applications but there are many other valid use cases for publicPath option. See BROCKHAUS-AG/AspNetAngular2IntegrationDemo for a simple demo ...

This should also fix #2276.

Cheers,
Fabian

[clydin]

Changing the base href doesn't do what you need?

[Mischi]

Hi,

using base href works kind of. The problem with using base href is that it will also affect ajax calls which in my case is not what i want ...

[clydin]

You can either use root relative urls or provide an app wide config object with an api base url which can be prefixed to all ajax calls (good practice anyway in case the static content is split from the API in the future).

The nice thing about setting the base href is that it handles index.html, webpack, and angular routing all in one place.

[Mischi]

You can either use root relative urls or provide an app wide config object with an api base url which can be prefixed to all ajax calls (good practice anyway in case the static content is split from the API in the future).

Yes, that works. Thanks!

But it doesn't feel correct to me though since my index.html is served on http://localhost:8080/ and all assets are below http://localhost:8080/Content/. Using base href would feel more correct if my index.html would be served from http://localhost:8080/Content/ too. But maybe that's just my lack of understanding as it seems to work with base href ....

Btw, my application structure looks like this:

• ClientApp (angular-cli project)
  • angular-cli.json
• Controllers
  • HomeController (serves ../Content/index.html on http://localhost:8080/)
• Content (outDir)
  • index.html
  • main.bundle.js
  • ...

[Mischi]

After playing a little bit more with --base-href i am pretty sure that --base-href is NOT what i want in my case.

I prepared two demos which demonstrate the difference between --basic-href and publicPath as i propose in this PR.

The --basic-href demo (http://ngcli-basehref.azurewebsites.net/) will use the --base-href "/Content" for routing too as you noticed which is not what i want.

If you compare this with the publicPath demo (http://ngcli-publicpath.azurewebsites.net/) you will notice, that /Content is only used for assets and not for routing.

@clydin, do you know a way i can archive this without publicPath?

Thanks in advance,
Fabian

[clydin]

Add this to your app module:

providers: [{provide: APP_BASE_HREF, useValue: '/'}]

As to the PR, I think that two options that perform similar functions but with slightly different outcomes could lead to confusion. Some guides on different hosting strategies would probably be useful regardless.

[Mischi]

Thanks again!

[jbellmann]

@Mischi
Why did you close this PR? You don't want it merged anymore? I have seen lots of issues about this "publicPath"-config option.

[Mischi]

Hi @jbellmann, the solution @clydin proposed works for my current project but if you care i can reopen it.

[andyg3]

The solution from @clydin doesn't work in my case. I definitely need publicPath supported.

[jbellmann]

@Mischi

please notice my PR into your feature-branch. Contains only the missing test.

[clydin]

@andyg3 feel free to open an issue to discuss your use case

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.

[jbellmann]

@here I signed the CLA, but somehow the @googlebot is not checking again.

[andyg3]

Is there a way to kick the @googlebot into re-checking this?

[changLiuUNSW]

Is there any update with this? I really need publicPath support.

[jbellmann]

@Mischi

I merged latest changes from master and created a PR for your feature-branch.

Is there an easier way to handle this?

Regards,
Jörg

[rsnj]

I really need publicPath support as well. Will be great to get this merged in.

[changLiuUNSW]

I think this one can be closed
Another PR created including command line support and unit test
#3285

[filipesilva]

Superseded by #3285, as it is more complete.

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