Add --deploy-url to application builder

@dgp1130

I am referencing following response from @dgp1130, where is stated that "team does not expect that any existing use cases to suddenly become unsupported". From v17 there is no possibility to reference static assets with absolute url. Using base hrefs is not proper replacement because relative links must stay relative to root when users wants to open links in new tab (ctrl + click) and also for non javascript consumers of server side rendered pages. Combinations with APP_BASE_HREF are not applicable for this use case. Due to this we believe this is regression for no good reason.

          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.

Originally posted by @dgp1130 in #22113 (comment)

Updated 23.2.2024 with minimal reproduction:
https://github.com/TheTomasJ/angular-router-example

We continued using Angular as our frontend because of this promise. Due to having a MVC Razor base page with important functionality for our site, we have used the technique of injecting our index.html into a razor page. This means that our .js and .css files are not hosted at the same URL as the base page. We have had some success with manually adding the URLs of the .js and .css files to our page, but this technique does not work with lazy loaded modules. I would imagine users that host their files on a CDN would have similar issues.

Had some discussion on this today. Our general stance is that --deploy-url is discouraged and we have found <base href> to be a less confusing alternative: https://angular.dev/tools/cli/deployment#--deploy-url. To be clear we still have not removed --deploy-url, it still exists in the browser and browser-esbuild builders.

We've been hesitant to add --deploy-url to application builder unless we find that it is a significant migration blocker for many applications. However, I think this issue would be helpful to collect feedback from the community, so I'll leave it open for now.

If moving off --deploy-url is viable but particularly challenging for you, then please thumbs up the issue so we know it's important to unblock adoption of application builder.

Separately, if you have a specific use case which requires --deploy-url (and is incompatible with <base href>), please post your use case here. We can use this data to inform the longer term future of --deploy-url and what use cases we might need to improve support for.

Hi, if it's discouraged... Can the docs be updated?

https://angular.io/guide/deployment

On the footer says Last reviewed on Mon Feb 28 2022

So perhaps new users need to understand why it doesn't work

@dgp1130

I'm creating a simple flask application, and don't want to manage the frontend assets with an external server.

Without setting baseHref, the built assets are expected to be requested from URLs like /main.<hash>.js.
The only way to configure flask to serve the asset in this location is to set static_url_path="/". We get a route list such as this:

Endpoint                            Methods  Rule
----------------------------------  -------  --------------------------------------
home.catch_all_route                GET      /
home.catch_all_route                GET      /<path:path>
static                              GET      /<path:filename>

Unfortunately, when defining this, the static_route overrides the catch_all that serves the index.html. When navigating to a frontend route, the server logically returns a 404 (it tried to find an asset file for that route and failed).

The hack by setting baseHref="/static" and APP_BASE_HREF="/" would work, but breaks all CTRL-click, which is 100% not acceptable (I mean, it's a dealbreaker, the kind that leads to migrate to another framework).

The only solution I found is to build using the browser builder as @dgp1130 suggested, set "deployUrl": "static/" and leave baseHref undefined. This way, Flask can be configured with static_url_path="/static" which gives the following routing table:

Endpoint                            Methods  Rule
----------------------------------  -------  --------------------------------------
home.catch_all_route                GET      /
home.catch_all_route                GET      /<path:path>
static                              GET      /static/<path:filename>

I get a warning that deployUrl is deprecated, which means that angular will stop working at some point :/

Hi, if it's discouraged... Can the docs be updated?

https://angular.io/guide/deployment#the-deploy-url states:

base href is generally the better option.

https://angular.dev/tools/cli/deployment#--deploy-url also discourages it.

The hack by setting baseHref="/static" and APP_BASE_HREF="/" would work, but breaks all CTRL-click

What Ctrl+click behavior are your referring to? Do you mean ctrl+clicking a link where the browser opens it in a new tab? I don't see how --deploy-url or <base href> would break that behavior.

Unfortunately, when defining this, the static_route overrides the catch_all that serves the index.html. When navigating to a frontend route, the server logically returns a 404 (it tried to find an asset file for that route and failed).

I'm not familiar with Flask specifically, but if I'm understanding your comment correctly it seems like it is not feasible to configure the server to both serve a static directory and also fallback to index.html on 404? Those don't feel like mutually conflicting requirements and I personally would expect that to be possible in any server. Is there a Flask feature request to support this or any reasoning from the Flask team for rejecting such a feature?

Just in case someone who don't know how to switch the builder from application to browser in the angular.json. Here is the diff for that:

Separately, if you have a specific use case which requires --deploy-url (and is incompatible with <base href>), please post your use case here. We can use this data to inform the longer term future of --deploy-url and what use cases we might need to improve support for.

My use case - I deploy my front-end to an app server, but then a CDN pull zone caches static assets and serves from the CDN.
I use --deploy-url to set the CDN url.

eg My app is at domain.com
CDN looks at domain.com and caches files to cdn.com
I build with --deploy-url=cdn.com and upload to domain.com
Users get index.html from domain.com, but all assets are served from cdn.com

We use angular/elements for building microfrontends with angular which each are hosted under a
separate deploy url (e.g. /microservice-1, /microservice-2, etc...). The main chunk is loaded into our shell at runtime. The index.html of the microservices will never be loaded by the shell and therefore baseHref is not working.

--deploy-url is necessary.
I just want to set cdn url, don't want to effect the router url.

They are different things. separate them.
Don't make things complicated.

@dgp1130

The hack by setting baseHref="/static" and APP_BASE_HREF="/" would work, but breaks all CTRL-click

What Ctrl+click behavior are your referring to? Do you mean ctrl+clicking a link where the browser opens it in a new tab? I don't see how --deploy-url or <base href> would break that behavior.

@dgp1130 The ctrl+click would be broken when we use a relative link. Say we serve a site on http://www.aaa.com/bbb, and the user ctrl+click a link like <a href="foo"></a>, then with baseHref="/static/" the browser would open http://www.aaa.com/static/foo, but the url we want to open is http://www.aaa.com/foo. Similar use cases include but are not limited to window.open(link), window.location = link, fetch(link), ...

Of course we could use javascript to intercept these cases and build an absolute url for use, but it's cumbersome and not intuitive. SDKs with business logic that are shared among sites built on different web frameworks would have to take it into account if we want to adopt them in Angular apps. There are also scenarios without javascript like SSR (used by crawler and SEO).

It seems the reasons to deprecate --deploy-url are about build speed and bundle size. I think developers should have a chance to choose between "intuitive relative link support" and "better build speed & bundle size" if we couldn't figure out a better solution to achieve both.

@dgp1130

@dgp1130 The ctrl+click would be broken when we use a relative link. Say we serve a site on http://www.aaa.com/bbb, and the user ctrl+click a link like <a href="foo"></a>, then with baseHref="/static/" the browser would open http://www.aaa.com/static/foo, but the url we want to open is http://www.aaa.com/foo. Similar use cases include but are not limited to window.open(link), window.location = link, fetch(link), ...

@Mensu That sounds like the typical behavior of <base href> to me? Is the click behavior different from ctrl+click in this scenario? I suspect this might be because ctrl+click opens in a new tab and thus performs a server-side navigation whereas click performs a client-side navigation. However if that's a problem then it is likely a configuration issue with your server.

If you can create a minimal reproduction of a scenario where click and ctrl+click behavior are different, then I would be very interested to see it.

The Angular CLI is generating our index.html file, mostly. We also insert some of our own necessary scripts and other content into the file as well, before we serve it from one of our main domains. Adding the prefix specified by deployUrl to all requests for files generated by ng build would, I think, do everything we need it to do. The only files we serve from the the deployUrl are the ones generated by ng build.

I don't think a manifest of file build outputs would be more useful, at least for our use case. A more extensive index.html templating option also would not help us here, I think, because what we add varies by endpoint, and has to be determined in our PHP application on our server.

As an aside, deployUrl is also really helpful for our development process. Each of our developers has a remote dev server with a full installation of our application (including both the Angular and non-Angular parts, etc), and runs ng serve on their local system. Developers set deployUrl to //localhost:4200/. We do have to rsync a copy of the generated index.html over to the dev server, but then it is possibly to run the application on the dev server exactly as if it were the production application, with localhost standing in for our CDN.

We have a different use case. Perhaps it's too edge case to consider for the new deployUrl option, but I'll share just in case a native solution can cover our needs as well. We do what many called out and have our app files hosted on a CDN domain (unique per environment) that differs from the domain serving the application to the user. However, we also do not use the CLI generated index.html file. We pull the generated resource tags (CSS, Script, and component tag) and inject them into an index.html file managed and hosted by our CMS. To get all this working without using the currently deprecated deployUrl option requires us to:

use a custom APP_BASE_HREF provider to detect the CMS index path in use at runtime
rely on @angular-builders/custom-webpack to
- update the webpack publicPath to a temporary token
- scrape the generated index.html tags to generate our own "embeddable" tags for the CMS index
perform a token replacement to insert the CDN URL at deploy time per environment

We haven't yet looked at moving to ng17 as we're waiting for angular-builders to add support for esbuild, but if we could simplify all of this with a deployUrl option and/or index templates, that'd be great.

In my use case, there is micro frontend (angular element) that used as hostile component or remote app in none angular host apps and all resource files are not the same host app assets path. To deprecate this --deploy-url hits so much the current implementation. I vote not to deprecating this --deploy-url.

feat(@angular-devkit/build-angular): add `deployUrl` to application b…

Thanks to the team for adding this feature to the application builder! Definitely appreciated!

Thank you very much for supporting and keeping this deployUrl.

@alan-agius4

Hi @alan-agius4,
I saw that your PR status above was merged and I'm wondering when or what version this deployUrl fix will be fully available?
Thanks in advance.

@tclyit

@tclyit, it will be available in 17.3 which will be released as the latest version later on today.

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

Sunbelt Computer Software

PL/B Language Development and Support

Navigation Menu

Repository navigation

Add `--deploy-url` to `application` builder #26411

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Sunbelt Computer Software

PL/B Language Development and Support

Add --deploy-url to application builder #26411

Description

Activity

jdwill916 commented on Dec 19, 2023

dgp1130 commented on Jan 3, 2024

dlh2 commented on Jan 7, 2024

CorentinDeBoisset commented on Jan 7, 2024

dgp1130 commented on Jan 8, 2024

doggy8088 commented on Jan 16, 2024

jeremyj11 commented on Jan 19, 2024

dominicbachmann commented on Jan 25, 2024

xunjianxiang commented on Jan 30, 2024

Mensu commented on Jan 30, 2024

dgp1130 commented on Jan 30, 2024

13 remaining items

karptonite commented on Feb 22, 2024

JamesInDenver commented on Feb 22, 2024

tclyit commented on Feb 27, 2024

karptonite commented on Mar 4, 2024

tclyit commented on Mar 4, 2024

tclyit commented on Mar 13, 2024

alan-agius4 commented on Mar 13, 2024

angular-automatic-lock-bot commented on Apr 13, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Add `--deploy-url` to `application` builder #26411