Allow mixing-in of CDN-only library dependencies

Expected Behavior

The self-contained build enables delivering ui5 apps with a much smaller footprint and allows for solid performance gains. However, a ui5 app today loses the ability to run a self-contained build as soon as it makes use of ui5 modules which are not available as npm dependencies. Although with the openui5-suite project a library is in the works, such a library would really only cover the sap.suite.ui.commons namespace. No statement that I am aware of is made regarding other sapui5 libraries, such as the VizCharts controls (sap.viz.ui5 namespace).

For these kinds of libraries which cannot (yet?) be added as npm dependencies, it would be helpful to have the possibility of marking those as CDN-only dependencies which are resolved during runtime. I’m not sure if such a proposal is feasible, but the intention behind this request is to face the reality that not all SAPUI5 libraries will be available as npm modules in the foreseeable future and still allow more ui5 apps (which are potentially using sapui5 modules) to also benefit from the capabilities of the ui5-tooling.

Current Behavior

A self-contained build will fail if sapui5 controls are being used in the app which cannot be resolved as dependencies during build time.

Steps to reproduce the issue

1. Include a sap.viz.ui5.controls.VizFrame control in the openui5-sample app
2. Trigger a self-contained build

Affected components (if known)

• ui5-builder
• ui5-server
• ui5-cli
• ui5-fs
• ui5-project
• ui5-logger

[codeworrior]

While I understand your proposal and see how it closes the gap of missing npm packages for SAPUI5 libraries, I think we should not implement it:

• first, it would draw resources from the team that is working on releasing most SAPUI5 libraries as npm packages
• second, omitting a subset of resources from the standalone bundle would not be enough, IMO. We would nevertheless need access to each resource at build time to determine the transitive dependencies and to package those as well (if they come from npm packages).

Technically, a simpler variant is already possible with the existing tooling. Custom bundles allow to define a “provided” section. Modules in that section are assumed to be available at runtime, but not packaged into the resulting bundle. This unfortunately is not the full solution yet, because transitive dependencies are not determined for such “provided” modules.

BTW: the resulting bundle would be version dependent. Whatever version was used at build time to create the bundle also has to be used at runtime to fill the gaps. Dependencies between libraries of the SAPUI5 distribution are not always limited to (stable and timeless) APIs, but often use internals. This prevents running a mixture of versions. But as versions don’t disappear from our CDN, the approach still would be possible, it just would have a version dependency that needs to be obeyed.

[RandomByte]

In the meantime we have improved the documentation on custom bundling: https://sap.github.io/ui5-tooling/pages/Configuration/#custom-bundling

Also, SAPUI5 libraries can now be consumed directly from npm: https://sap.github.io/ui5-tooling/pages/SAPUI5/

From my understanding these were the two main points discussed here. Since they are both resolved now, I’ll close the issue for the time being.