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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include WebComponent Distributions from Arbitrary Subdirectory #2167

Closed
codefactor opened this issue Sep 1, 2020 · 1 comment · Fixed by #2214
Closed

Include WebComponent Distributions from Arbitrary Subdirectory #2167

codefactor opened this issue Sep 1, 2020 · 1 comment · Fixed by #2214
Assignees
Milestone

Comments

@codefactor
Copy link
Contributor

codefactor commented Sep 1, 2020

Is your feature request related to a problem? Please describe.
We are running the build on a project (@xweb/common-webcomponents) and then deploying that code into a deeply nested directory which actually embeds the version number of the library into the directory, that way the server can respond with very strong cache-control headers, allowing Caching Proxies (like Akamai) and browsers to cache these files with no need to check for changes.

Everything basically works, except for the following error:

FetchHelper.js:20 GET http://localhost:8080/resources/en.c4465af466100b5b.json 404 (Not Found)

Note that currently the startup of the code does not actually need this JSON file to work, but likely there is some nested functionality broken because of this issue (e.g. some sort of localization in some popup).

The issue is that this JSON file's path is hard coded somewhere to be served from the directory like /resources but in actuality the file is available at a location like this:

http://localhost:8080/verp/vmod_x/ui/common-webcomponents/resources_1.0.0-rc.26/dist/resources/en.c4465af466100b5b.json

Describe the solution you'd like
We would like a way to tell the UI5 web components library where the resources directory is located. Maybe you can do one or all of the following:

  1. Read the resource path from an identified bootstrap script tag with a known id

The bootstrap tag would then indicate to the ui5 web component library where the resources directory is located by assuming it is the same directory where the bootstrap script src file is located.

<script id="ui5-webcomponent-bootstrap" src="/verp/vmod_x/ui/common-webcomponents/resources_1.0.0-rc.26/dist/resources/bundle-esm.js" />
  1. Utilize a global variable
<script>
  window['sap-ui-webcomponents'] = {
    resources: '/verp/vmod_x/ui/common-webcomponents/resources_1.0.0-rc.26/dist/resources/'
  };
</script>
  1. Have a public API function
import { setResourcesDirectory  } `@ui5/webcomponents/path/to/file';

// hard-coded for example purpose, but this would need to be dynamically constructed in actuality
setResourcesDirectory('/verp/vmod_x/ui/common-webcomponents/resources_1.0.0-rc.26/dist/resources/');

In my opinion, all 3 are useful ways and perhaps the best way is to do all of them, though probably option 1 and 2 are sufficient to cover 99% cases. If you think about how UI5 does it, I think they essentially have all 3 ways available today in their own way: 1) bootstrap ui5 tag, 2) window['sap-ui-config'].resourceRoots, 3) setting the resourceRoots after boot

Describe alternatives you've considered
We're not sure if there is any other solution.

Additional context
Add any other context or screenshots about the feature request here.

@vladitasev
Copy link
Contributor

While we are working on a runtime configuration, please also consider an already existing undocumented option that we are planning to make public:

You can set the env var DEPLOY_PUBLIC_PATH before running yarn build for the production build. You can thus specify a different path (/resources/ is used if var not supplied).

Taken from our deploy.sh script for example:

  # Run the build again so rollup can generate the correct public path urls
  cd $TRAVIS_BUILD_DIR
  DEPLOY_PUBLIC_PATH=https://sap.github.io/ui5-webcomponents/assets/js/ui5-webcomponents/ yarn build:playground

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants