You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
How to set 'publicPath' in webpack after 'deployUrl' option is deprecated in version 15 #22113
That's also an issue for us. We have a widgets application that contains multiples lazy loaded custom elements. These elements are used in other applications. When some element want to load an image it should be loaded from the widgets domain, not from the current one that belongs to main application. Currently this can be achieved by using deploy-url during widgets app build. How to do it without this option?
@artaommahe, in that case there is no alternate option for that. One thing to point out is that this aligns the behaviour of images defined in HTML and CSS, which results in images URI HTML to always be relative to HTML.
What comes to mind is to have an external CSS file (styles.css) that you defined the image in, since images are loaded relative to the stylesheet origin. Though this might be a bit cumbersome.
@alan-agius4 using global css file breaks lazy loading of such stuff, locality of code (images of some component from one of the widgets lib somehow are placed in global styles file).
This looks strange due to availability of official @angular/elements and breaks their usage for micro-frontend cases.
If the assets can be referenced from the component templates instead, another option is to generate the full asset URL at runtime via the use of import.meta.url. This is similar in functionality to the deprecated deploy URL option but has the advantage of not needing to hardcode anything other than the relative path of the asset. The JavaScript and asset files as a whole could then potentially be served from locations other than a predefined deploy URL and still function.
This method is unfortunately not possible with stylesheets since they are fixed at build time. However, if stylesheets are required in this context, they could potentially be external but dynamically loaded to retain lazy loading semantics.
@feng-xiao, can you please elaborate on why you need the deployUrl option and the specific use-case?
@artaommahe, is the image located in component stylesheet or external stylesheet?
Hi @alan-agius4 , I've integrated Angular app into an ASP.NET MVC application, i.e. the Angular app is initialized by a MVC razor view. Since the Angular resources are generated and hosted in different port number in 'ng serve' mode than MVC app, e.g. ASP.NET MVC app is loaded in localhost:8444, Angular app would be loaded in different port number like localhost:8445, I need to make Angular resources loaded using absolute URL, otherwise, they'll be loaded in wrong URL, the one MVC is using (i.e. localhost:8444).
Reacted by Volodymyr Volodin, scarabedore and Ivan Milicevic
@feng-xiao, can you please elaborate on why you need the deployUrl option and the specific use-case? @artaommahe, is the image located in component stylesheet or external stylesheet?
Hi @alan-agius4 , I've integrated Angular app into an ASP.NET MVC application, i.e. the Angular app is initialized by a MVC razor view. Since the Angular resources are generated and hosted in different port number in 'ng serve' mode than MVC app, e.g. ASP.NET MVC app is loaded in localhost:8444, Angular app would be loaded in different port number like localhost:8445, I need to make Angular resources loaded using absolute URL, otherwise, they'll be loaded in wrong URL, the one MVC is using (i.e. localhost:8444).
Hi @alan-agius4 , based on webpack's source code, I don't see any overhead by setting 'publicPath' to webpack config. I don't know why Angular Doc says it could increase build time.
@feng-xiao, the deployUrl, is used not just to set the publicPath, using deployUrl will cause additional steps including processing all CSS templates and files to append the deployUrl to the assets urls.
Another disadvantage of using deployUrl, is that the string value will be included all over the bundle multiple times, which causes an increase in bundle size and make promotion of bundles from one environment to another rather tricky.
In your cases, the recommended approach would be to use a combination of both --base-href and APP_BASE_HREF.
@alan-agius4 We heavily use too the deployUrl parameter. For us, it's because we have a reverse proxy that route all requests under (base-href)/static (if the load is too high) to a dedicated apache server, because we serve angular through a tomcat server most of the time (embedded jar for a Spring Boot application).
If this parameter is removed, we're just screwed :/
Also, the context path, in tomcat, must match base-href for angular to work correctly. And last, but not least, requests served to /context/path/ are protected by an SSO platform (OpenAM), whereas, those under /context/path/static are not, because considered safe (not enforced policy) by convention. So the SSO agent is free from checking if requests behind static are legitimate or not, what drastically reduces load. Hope it's understandable.
TLDR : we'd love to keep the option to have both base-href and deployUrl (or whatever it's named) configurable.
This causes problems with our setup too. We use Spring Boot to serve the Angular app. The app is being built under resources/static/dist. Spring by default serves content from the resources/static folder, we use a subfolder so that we can restrict access to resources but whitelist the Angular app. We set the deployUrl to dist/ to make this setup work. The index.html is served as a Thymeleaf template with the base href set to the context path of the server, we do not use the index.html generated during build.
E.g. suppose the server runs on http://my-domain.com/foo then we set the base href to /foo/, the app resources are available at http://my-domain.com/foo/dist.
With the deprecation of deployUrl we need to set the base href to /foo/dist/ for the assets to be loaded but this results in API requests going to /foo/dist/api whereas we need them to go to /foo/api.
Obviously there are ways around it (the best one currently being using deployUrl while we still can), but I would like to know what an elegant solution to this problem could be.
We also have problems with the deprecation of deployUrl.
Our server serves two Angular applications from the same path depending on whether the user is authenticated or not, with the help of deployUrl, we could set each application's assets paths to separate them on the server. In this case if user load http://example.foo/ and they are not authenticated, the server can serve lets say LoginApplication which has deployUrl set to assets/login/, once they are authenticated the server serves lets say DashboardApplication which has deployUrl set to assets/dashboard/.
APP_BASE_HREF does not help us because it changes the browser URL to assets/login/ or assets/dashboard/.
Any idea how this can be handled without deployUrl?
Reacted by Miloš Stanić, Luis Almanzar and maxwellfargoseCactus
How to use deployUrl correctly and what problems it is good / not good for has been a difficult area for the community. We've done our best to assist folks where possible, but this is a big enough issue that our attempts to do so haven't really scaled effectively. After some discussion, we think the best path forward here is to update some of our docs to be more clear about various aspects and also write a blog post which discusses some common use cases where devs typically reach for deployUrl and how our official recommendation for how to handle those requirements. That seems like the most scalable approach addressing the confusion around deployUrl.
I'm closing this issue for now as we don't see anything directly actionable here, but hopefully better documentation and a future blog post will help clarify how best to meet your requirements.
Reacted by mbassit, Silverlancer, Bruce Lam, Sandro, Yuriy Grunin, Damien Leroy, Pavel Shurygin, rekna1, brz, matrium0 and 2 more
@dgp1130 Could you clearly describe what will happen to deployUrl? Will that property still pending on removal or Angular will keep that functionality.
People who posted here, or at least for me need an clear path of whether deployUrl will be removed or not. Documentation and recommendation is good, but if the functionality will be removed, we need to plan ahead.
Reacted by James Albright, Bruce Lam, Yuriy Grunin and Szymon
We are still planning to remove deployUrl eventually largely because of all the confusion it causes. The exact version it gets dropped is still TBH, but I can confidently say it will not be removed in v14, so this shouldn't be an immediate problem for anyone. The blog post in particular should hopefully help address common use cases which have used deployUrl in the past and how we recommend moving forward for each of them. We're not expecting any existing use cases to suddenly become unsupported, just that the right approach for you will probably vary by your particular requirements.
Reacted by Silverlancer, Maksim Popov, Miloš Lajtman and Csaba Tamás
@benjaminadrom tey a solution posted by @ThomasDevens above. It worked for me.
thanks, but
APP_BASE_HREF' useValue did not change the base href inside the generated index, so his solution as I understood was to replace those links that manually, which feels like an unnecessary hack somehow
angular-automatic-lock-bot commented on Jun 16, 2022
Activity
artaommahe commentedon Nov 8, 2021
That's also an issue for us. We have a widgets application that contains multiples lazy loaded custom elements. These elements are used in other applications. When some element want to load an image it should be loaded from the widgets domain, not from the current one that belongs to main application. Currently this can be achieved by using deploy-url during widgets app build. How to do it without this option?
alan-agius4 commentedon Nov 8, 2021
@feng-xiao, can you please elaborate on why you need the deployUrl option and the specific use-case?
@artaommahe, is the image located in component stylesheet or external stylesheet?
artaommahe commentedon Nov 8, 2021
@alan-agius4 in component's scss files
alan-agius4 commentedon Nov 8, 2021
@artaommahe, in that case there is no alternate option for that. One thing to point out is that this aligns the behaviour of images defined in HTML and CSS, which results in images URI HTML to always be relative to HTML.
What comes to mind is to have an external CSS file (styles.css) that you defined the image in, since images are loaded relative to the stylesheet origin. Though this might be a bit cumbersome.
artaommahe commentedon Nov 8, 2021
@alan-agius4 using global css file breaks lazy loading of such stuff, locality of code (images of some component from one of the widgets lib somehow are placed in global styles file).
This looks strange due to availability of official
@angular/elementsand breaks their usage for micro-frontend cases.clydin commentedon Nov 8, 2021
If the assets can be referenced from the component templates instead, another option is to generate the full asset URL at runtime via the use of
import.meta.url. This is similar in functionality to the deprecated deploy URL option but has the advantage of not needing to hardcode anything other than the relative path of the asset. The JavaScript and asset files as a whole could then potentially be served from locations other than a predefined deploy URL and still function.This method is unfortunately not possible with stylesheets since they are fixed at build time. However, if stylesheets are required in this context, they could potentially be external but dynamically loaded to retain lazy loading semantics.
feng-xiao commentedon Nov 8, 2021
Hi @alan-agius4 , I've integrated Angular app into an ASP.NET MVC application, i.e. the Angular app is initialized by a MVC razor view. Since the Angular resources are generated and hosted in different port number in 'ng serve' mode than MVC app, e.g. ASP.NET MVC app is loaded in localhost:8444, Angular app would be loaded in different port number like localhost:8445, I need to make Angular resources loaded using absolute URL, otherwise, they'll be loaded in wrong URL, the one MVC is using (i.e. localhost:8444).
feng-xiao commentedon Nov 8, 2021
Hi @alan-agius4 , based on webpack's source code, I don't see any overhead by setting 'publicPath' to webpack config. I don't know why Angular Doc says it could increase build time.
alan-agius4 commentedon Nov 9, 2021
@feng-xiao, the
deployUrl, is used not just to set thepublicPath, usingdeployUrlwill cause additional steps including processing all CSS templates and files to append thedeployUrlto the assets urls.Another disadvantage of using
deployUrl, is that the string value will be included all over the bundle multiple times, which causes an increase in bundle size and make promotion of bundles from one environment to another rather tricky.In your cases, the recommended approach would be to use a combination of both
--base-hrefandAPP_BASE_HREF.Razor View
app.module.ts
mpalourdio commentedon Nov 9, 2021
@alan-agius4 We heavily use too the deployUrl parameter. For us, it's because we have a reverse proxy that route all requests under
(base-href)/static(if the load is too high) to a dedicated apache server, because we serve angular through a tomcat server most of the time (embedded jar for a Spring Boot application).With the deployUrl we currently have
If this parameter is removed, we're just screwed :/
Also, the
context path, in tomcat, must matchbase-hreffor angular to work correctly. And last, but not least, requests served to/context/path/are protected by an SSO platform (OpenAM), whereas, those under/context/path/staticare not, because considered safe (not enforced policy) by convention. So the SSO agent is free from checking if requests behindstaticare legitimate or not, what drastically reduces load. Hope it's understandable.TLDR : we'd love to keep the option to have both base-href and deployUrl (or whatever it's named) configurable.
A full example project is here : https://github.com/mpalourdio/SpringBootAngularHTML5
35 remaining items
lulzzz commentedon Mar 26, 2022
I also need deploy URL, otherwise the chunks are not loaded correctly.
APP_BASE_HREF is not the solution.
icguy commentedon Mar 31, 2022
This causes problems with our setup too. We use Spring Boot to serve the Angular app. The app is being built under
resources/static/dist. Spring by default serves content from theresources/staticfolder, we use a subfolder so that we can restrict access to resources but whitelist the Angular app. We set the deployUrl todist/to make this setup work. The index.html is served as a Thymeleaf template with the base href set to the context path of the server, we do not use the index.html generated during build.E.g. suppose the server runs on
http://my-domain.com/foothen we set the base href to/foo/, the app resources are available athttp://my-domain.com/foo/dist.With the deprecation of deployUrl we need to set the base href to
/foo/dist/for the assets to be loaded but this results in API requests going to/foo/dist/apiwhereas we need them to go to/foo/api.Obviously there are ways around it (the best one currently being using deployUrl while we still can), but I would like to know what an elegant solution to this problem could be.
Luladjiev commentedon Mar 31, 2022
We also have problems with the deprecation of
deployUrl.Our server serves two Angular applications from the same path depending on whether the user is authenticated or not, with the help of
deployUrl, we could set each application's assets paths to separate them on the server. In this case if user loadhttp://example.foo/and they are not authenticated, the server can serve lets sayLoginApplicationwhich hasdeployUrlset toassets/login/, once they are authenticated the server serves lets sayDashboardApplicationwhich hasdeployUrlset toassets/dashboard/.APP_BASE_HREFdoes not help us because it changes the browser URL toassets/login/orassets/dashboard/.Any idea how this can be handled without
deployUrl?dgp1130 commentedon Apr 14, 2022
How to use
deployUrlcorrectly and what problems it is good / not good for has been a difficult area for the community. We've done our best to assist folks where possible, but this is a big enough issue that our attempts to do so haven't really scaled effectively. After some discussion, we think the best path forward here is to update some of our docs to be more clear about various aspects and also write a blog post which discusses some common use cases where devs typically reach fordeployUrland how our official recommendation for how to handle those requirements. That seems like the most scalable approach addressing the confusion arounddeployUrl.I'm closing this issue for now as we don't see anything directly actionable here, but hopefully better documentation and a future blog post will help clarify how best to meet your requirements.
Nness commentedon Apr 14, 2022
@dgp1130 Could you clearly describe what will happen to
deployUrl? Will that property still pending on removal or Angular will keep that functionality.People who posted here, or at least for me need an clear path of whether
deployUrlwill be removed or not. Documentation and recommendation is good, but if the functionality will be removed, we need to plan ahead.dgp1130 commentedon Apr 14, 2022
We are still planning to remove
deployUrleventually largely because of all the confusion it causes. The exact version it gets dropped is still TBH, but I can confidently say it will not be removed in v14, so this shouldn't be an immediate problem for anyone. The blog post in particular should hopefully help address common use cases which have useddeployUrlin the past and how we recommend moving forward for each of them. We're not expecting any existing use cases to suddenly become unsupported, just that the right approach for you will probably vary by your particular requirements.ThomasDevens commentedon Apr 18, 2022
Had this same issue but found a solution that worked for me - https://stackoverflow.com/questions/71695674/what-is-best-way-to-go-about-replacing-deployurl-in-angular-json-for-v13/71913980#71913980
AGuyCoding commentedon May 13, 2022
did you ever managed to work things out with omit deployUrl and using APP_BASE_HREF?
miluoshi commentedon May 15, 2022
@benjaminadrom tey a solution posted by @ThomasDevens above. It worked for me.
AGuyCoding commentedon May 16, 2022
angular-automatic-lock-bot commentedon Jun 16, 2022
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.