Support self-contained build without fallback dependency modules

[BenReim]

Is your feature request related to a problem? Please describe.

If a self-contained build with dependencies is performed, all framework dependencies will be also be included as non-bundled version. Although this behaviour makes sense as fallback option in case any resources were not included in the bundling, it would be good if it can be configured.

Describe the solution you'd like

In given sample application project:

• Dependency to sap/m
• Supported Theme: Horizon
• Support Language: EN

It shall be possible to run a minimal self-contained build...

ui5 build self-contained --all

...that results in the following build output (simplified and no consideration of debug sources):

dist/
├── index.html
├── Component-preload.js
└── resources/
    ├── sap-ui-custom.js
    ├── ui5loader.js
    └── sap/
        ├── ui/
        │   ├── core
        │   └── messagebundle.properties/
        │       └── themes/
        │           └── sap_horizon/
        │               └── library.css
        └── m/
            ├── messagebundle.properties
            └── themes/
                └── sap_horizon/
                    └── library.css       

[RandomByte]

Yes, this really makes sense. Since CSS files can't be bundled, you basically always have to use the --all build optional to include them (and all the other files) in the build result.

I guess the main problem is that we don't know which JavaScript files might be required at runtime. So we would really like all of them to be available. I can see how we could omit all files that are part of the self-contained bundle from being written out separately, but I think you'd expect more, right?

May I ask, how is this enhancement motivated? To reduce the deployment size? Would you expect debug sources to still be part of the build result?

[BenReim]

I guess the main problem is that we don't know which JavaScript files might be required at runtime.

To be honest, I didn’t think much of aspect. My assumption was that all dependencies can be determined at build time.

May I ask, how is this enhancement motivated? To reduce the deployment size?

Yes, my primary motivation is a significant size reduction of the deployment archive, along with performance gains in C/I (e.g. stashing of the build artefact between Jenkins nodes)

Would you expect debug sources to still be part of the build result?

Yes I guess I would expect the debug sources to be there for all dependencies that are also part of sap-ui-custom.js bundle.

[RandomByte]

My assumption was that all dependencies can be determined at build time

Just to clarify: All dependencies determined at build time will of course be added to the self-contained bundle. The problem are those dependencies that we fail to detect (for example due to dynamic requires) and hence not add to the self-contained bundle.

If those modules are not part of the build result, but the runtime suddenly needs to load them, the application might break.

Thanks for your additional input, we'll discuss this in the team 👍