How to set 'publicPath' in webpack after 'deployUrl' option is deprecated in version 15

[feng-xiao]

angular-cli/packages/angular_devkit/build_angular/src/webpack/configs/common.ts

Line 335 in 5402f99

publicPath: buildOptions.deployUrl ?? '',

[artaommahe]

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]

@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]

@alan-agius4 in component's scss files

[alan-agius4]

@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]

@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.

[clydin]

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]

@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).

[feng-xiao]

@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.

[alan-agius4]

@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.

Razor View

...
<base href="http://localhost:8445/">
...

app.module.ts

...
{ provide: APP_BASE_HREF, useValue: 'http://localhost:8444' }
...

[mpalourdio]

@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

<!DOCTYPE html><html lang="fr">
  <head>
    <base href="/context/path/">
    <meta charset="utf-8">
    <title>My application...</title>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="icon" type="image/png" href="static/favicon.png">
    <link rel="stylesheet" href="static/styles.8277a10e7c2be6c58f14.css" media="print" onload="this.media='all'">
</head>
<body>
    <app-root>loading...</app-root>
<script src="static/runtime-es2017.5a110097badef840dfda.js" type="module" crossorigin="use-credentials"></script>
<script src="static/runtime-es5.5a110097badef840dfda.js" nomodule defer></script>
<script src="static/polyfills-es5.1f50460b6153455d79c6.js" nomodule defer></script>
<script src="static/polyfills-es2017.acf5917270495d93417a.js" type="module" crossorigin="use-credentials"></script>
<script src="static/main-es2017.f3526c48e4006bc6f2e3.js" type="module" crossorigin="use-credentials"></script>
<script src="static/main-es5.f3526c48e4006bc6f2e3.js" nomodule defer></script>
</body>
</html>

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.

A full example project is here : https://github.com/mpalourdio/SpringBootAngularHTML5