Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoiding app rebuild for a different deployUrl, dynamic deployUrl resolution at runtime #16625

Open
santam85 opened this issue Jan 10, 2020 · 2 comments

Comments

@santam85
Copy link

@santam85 santam85 commented Jan 10, 2020

馃殌 Feature request

Being able to deploy angular apps in different environments without necessarily having to rebuild them. I found several related issues, but none of them was closed in a satisfactory way. It seems a lot of people also confuse the purpose of baseHref and deployUrl.

Command (mark with an x)

  • new
  • [ x ] build
  • serve
  • test
  • e2e
  • generate
  • add
  • update
  • lint
  • xi18n
  • run
  • config
  • help
  • version
  • doc

Description

At the moment, the only reliable option I could find to make sure my application sources can be served from a CDN is to leverage the deployUrl option offered by the CLI, which is in turn using output.publicPath from Webpack.

The current implementation implies that the final CDN url needs to be known at build time, and that deployment to a different CDN (ie. DEV vs PROD environment) requires a rebuild of the application.

This is IMHO not acceptable, since it prevents me to reuse the same artifacts when promoting a build across DTAP environments, and impacts the portability of an application.

While I could figure out an easy alternative for environment options and baseHref, with a bit of support from SSR and nginx, I couldn't work around the issues i found with deployUrl.

Describe the solution you'd like

Developers should be allowed to inject custom asset url resolver logic that allows to retrieve and consume the deployUrl at runtime, not only statically at buildtime. This should apply both to lazy-loaded modules and possibly to resources referenced in SASS files.

Perhaps deriving the right URL of the CDN by using the value of a custom <meta> tag in the index.html could be a very convenient way to have it dinamically resolved by the webserver. In alternative, it should be possible to customize the provider responsible to retrieve such value at runtime, similarly to what we can do with https://angular.io/api/common/APP_BASE_HREF

Describe alternatives you've considered

I tried a custom webpack builder and I had some success using __webpack_public_path__ for lazy-loading of modules. This was not enough to correctly resolve references to external resources in scss files.

@santam85

This comment has been minimized.

Copy link
Author

@santam85 santam85 commented Jan 22, 2020

@filipesilva happy to have a look myself at possibilities here, could you offer some guidance to figure out how the "deployUrl" parameters ends up being used by the scss loader?

@clydin

This comment has been minimized.

Copy link
Member

@clydin clydin commented Jan 22, 2020

The deploy URL option is fundamentally a build time construct. It is not intended to be a runtime controllable value nor can it as it is injected throughout the output files. This includes the HTML index file via the application script locations and CSS files (both global and component) which must hard-code the value to be considered valid CSS.

The HTML base HREF, however, is the exact opposite and is instead a runtime construct that is applied by the browser itself. It exists in only one location within the entire application (the HTML index file). Its primary purpose is to alter the retrieval location of relatively referenced resources. It can also be dynamically adjusted at runtime by modifying the value in the DOM. An inline script within the head element, for instance, could be used to alter the value based on some criteria before any other scripts/resources are loaded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can鈥檛 perform that action at this time.